There's been a lot of debate in the python blog community about which web framework is best for everyone else. There's also been a hot debate about templating languages much fueled by Guido's rejection of XMLish requirements. In the few blogs I've followed there seems to be a couple of finalists that deserve extra scrutiny: Zope3, Django and TurboGears.
I'm drooling over all of them. Zope3 feels like a wise granddad with vigour, Django as a bubblegum-chewing teenager with lots of energy and TurboGears as something in between. (if Twisted was to get an analogy it'd be Einstein or someone like that) I want to use all three or at least Zope3 and one of Django or TurboGears depending on the project. Stuff that needs thinking and will have to last and scale: Zope3. Quick and simple websites about a single topic: Django/TurboGears.
To the point, I ran a sloccount on django (from SVN), Zope 3.2.0 (for zope.org) and TurboGears 0.8.8 (from turbogears.org). The difference is big. Here are the results:
TURBOGEARS 8.8
python: 26976 (99.55%)
sh: 123 (0.45%)
Total Physical Source Lines of Code (SLOC) = 27,099
DJANGO (SVN)
python: 17720 (100.00%)
Total Physical Source Lines of Code (SLOC) = 17,720
ZOPE 3.2.0
python: 362334 (96.47%)
ansic: 13058 (3.48%)
sh: 178 (0.05%)
perl: 37 (0.01%)
Total Physical Source Lines of Code (SLOC) = 375,607
(all values excluding blank lines but including comments)
This really has to be taken with a pinch of salt because Zope 2.8 weights in at about 270,000 loc and even though it accomplishes a lot it's not going to get much better. Also, bare in mind that Zope3's .py files comes with a little licensing comment at the beginning of almost all files which I estimate to amount to about 40,000 loc.
Zope3 is shipped with about 8,032 unit tests which takes up a lot of the total 375,000 but I don't know how much, but it doesn't matter because unit tests are valuable code just like comments are valuable too.
Does this make Zope3 a bloated beast? NO! Remember that unlike Zope2, Zope3 hasn't organically evolved but has been designed more or less from nothing but inspiration and thought. One of it's core features is the component architecture which puts in plenty of padding between the modules. Does this make Django/TurboGears a quick hack with a lot of hype? NO! If you listen to people who've actually used these, they do get things done and remember that many websites needn't be as complicated as Windows Update or Yahoo!. But, do appreciate the incredible power that this gives a Zope3 user. Imagine how many todo-list screencasts 375,000 lines of code would correspond to if TurboGears's video was 20 minutes for 27,000 lines of code. (hint: the answer is 4.5 hours)
UPDATE
Errata. Zope 3.2.0 source package comes with 8,032 unit tests, not 1,800 like I wrote the first time. Sh*t! That's a lot of unit tests. How can that not be pythonic? :)
Comments
Post your own commentI'm not saying Zope3 is a bloated beast, but building something from nothing doesn't mean it won't be bloated.
Having 20x as much code as others also doesn't mean it's better. I'm sure it has features others don't, but that doesn't necessarily mean they are useful to others.
I'm sure Zope3 is a fine product even if I'll never touch Zope2 again. But this statistics hardly tells you anything apart that Zope3 is big. Personally I'd be surprised if that also meant fast.
Wow. Those are some interesting stats, but I really don't know what they mean. Yes, it is more useful when you break down the code by category. Also remember that Zope comes bundled with the Zope Object Database (ZODB) for its own data persistence, which is a huge project by itself. TG and Django "outsources" data persistence to a separate relational database like MySQL, PostgreSQL, SQLlite, etc. (I'm curious to see the line count after the ZODB is factored out. Or what TG/Django looks like when you include the loc count of PostgreSQL source.
Regardless, I'm sure there are lots of opinion pieces out in the wild that warn of misinterpreting what loc counts mean. (For example: http://www.martinfowler.com/bliki/CannotMeasureProductivity.html)
(Disclosure: Fowler and I both work at ThoughtWorks.)
But yes, it's good to see Zope3's name thrown into the ring and be part of the conversation/debate/argument/battle royale that defines the Python Zeitgeist.
By my off-the-cuff run of sloccount, it looks like ZODB is about 125,000 LOC.
I'm currently using zope 2.8 with Postgresql, so if you were going to compare
it to TG/Django you would have to add the LOC of Postgresql to zope and TG/Django. I'm considering moving to Django, mainly because of its Postgresql/Relational Database orientation. I also believe performance will be better than Zope. Of course looking at a new framework is sort of like the backup quarterback. Everyone wants the backup to start, and then once he does .... Well, lets just say he is no longer the backup QB.
I wish more people would look at this "debate" like you do. So many people forget that their individual use case isn't the same one that everyone else has. Some people have simple needs that "larger" systems don't address very well; some people really need all those complexities. I see no single tool that's right for every job.
This doesn't mean that people shouldn't try to find ways to make larger systems more accessible and smaller ones more capable, but recognition that different people face different problems would make for more progress on this front.
Ok, isn't it about time to shed the myth that Zope3 isn't in any way connected to that miserable sonofa bitch Zope2?
I mean, they've been written by the same people, have the same bloat of code (yes bloat! Bloat is a function weather you're able to fix the framework you work with or not, can you fix Zope3?), they share a helluva lot of concepts.
Ohwait, there's a difference. Documentation for Zope3 is even scarcer then for Zope2...
I'd like to be happy for Zope3 (and no, I think it's relatively quite small). But here's what I see: No online documentation. What docs there are are just scribbed with "TODO". A grand total of a half-dozen packages, the latest being updated in 2004. The Postgresql DA didn't even work with the current version, and still doesn't work with psycopg2.
I'm sure there's great things that could be done with Zope3. They seem to be doing an excellent job at hiding any evidence that anything is being done or can be done with it.
Chuck, there is a lot of online docs within Zope3 under the /++apidoc++ namespace. And there are two books in existence about Zope3. Zope3 could still use a lot of tutorials though.
And I've been using PostgreSQL with Zope3 for over a year now, with the psycopg2 adapter. Admittedly Zope3 _strongly_ focuses on the ZODB and provides little assistance in translating the object model into SQL tables/records, but certainly SQLMethods work.
The one item you're spot on about is that there is no significant/current set of add-ons for Zope3 the way there was for Zope2. I'm not sure why that is though.
Nice to hear. I'm a big fan of Postgresql+zope2 and glad to hear that you go for sqlmethods instead of some forced-in solution of pretending that SQL is like OO but with different syntax.
sloccount doesn't include comments in the number of lines reported. You can make a simple test to check this. So, that 40,000 loc really counts.