Who cares about zope? - Martijn Faassen (djangocon.eu keynote)¶

Tags: djangocon, django, zope

Note beforehand. Martijn Faassen is well known in the zope world. Remember zope? The python web framework that used to have the buzz that django has now? I remember two europython conferences where one of the three tracks was zope/plone-only. Those europython conferences were one of the things he started, btw. So I expect a bit of a history lesson and some valuable input from another python web framework and perhaps some community organizing comparisons. We’ll see! Now on to the actual summary.

Martijn wrote/started a couple of things: formulator, five (zope3 in zope2), lxml, grok webframework, etc. He started python programming in 1998. And around that time he also started with zope: yes, it is that old.

In 2008 at djangocon, there was a talk by Mark Ramm about what django could learn from zope. Matt is a turbogears guy, btw. The reactions were pretty harsh sometimes, like “we lost a whole generation of web programmers to zope” and “django is an anti-zope”.

Some inflammatory comments to start off the discussion in the internet forums. Just to get it over with :-)

• Django now has class-based views. Zope’s class based views are from 2004. (In his presentation he called it generic views, btw).

• Django’s unicode support is from 2007. Zope’s was 2002.

• NoSQL is popular right now. Zope had the nosql zodb database from the start.

• Na na na na na :-)

Summary: django is great, but we could still learn a bit from zope. Also from the mistakes.

The start of zope was on a plane with Jim Fulton heading out to teach a cgi programming class in 1996. He thought it could be more object oriented so he started coding… Zope was open sourced by the company (Digital Creations) in 1998. At the time it was Huge News! A small company open sourcing its product! That didn’t happen often! It wouldn’t be news now, but it was at the time.

A core item from zope: object publishing. A URL is interpreted as a path to a model in a model hierarchy (=tree structure). Much like with a filesystem path, but with objects. When the model is found, it must be rendered for the web with a view. The tree traversal is also useful for security, again just like with a filesystem. The object itself knows where in the tree it is and so it knows its url.

In contrast, django uses url pattern matching. The url points at a view function which renders something. The function might grab some objects from the ORM.

In zope, a view is given a model and renders it. In django, the view itself looks up the model.

What’s the advantage of such a tree traversal mechanism instead of url pattern matching?

• You can design your app around your models.

• You can design generic, reusable views. For instance a generic, default “edit” view.

• You can compose and recombine models without having to map or remap lots of URLs. In practice: you can stick anything in every kind of folder if you need it. And you can have virtually infinite nesting.

• You can more easily add a view in one app for a model defined in another app.

There is also a drawback:

• More indirection. You cannot look up a urls.py with full info about which goes where.

Now some comments about community. Zope 10 years ago had meetups, BBQs, sprints. Zope was popular. Conferences like europython gained many visitors because of people coming for the zope track. Many python developers came to python through zope.

There was a disconnect between zope and the regular python community. Zope did things their own way, partially out of necessity. Some of those ways later turned out to be un-pythonic, but some of the zope solutions ended up in python itself! A big problem was zope’s Z-shaped learning curve (that’s NOT how you want your learning curve to be). Easy to start out with, but after a while…

Pythonic: lack of pythonicity makes it hard to get into python coming from plone. Or harder to get from python to zope. But python changes, so what’s pythonic changes. Take module names for instance. They’re lowercase now. Zope is old enough to still have CamelCase.py module names. On the other hand, some zope things like metaclasses even ended up in python itself, so that’s more pythonic now.

Django is pretty pythonic. But wsgi is now the pythonic thing and django doens’t do it that fully. And external dependencies are pythonic now and django has a lot build-in. So django is also slowly becoming more un-pythonic.

Zope’s answer to the un-pythonicity was a complete rewrite. Zope2 became zope3. Summary: don’t do a total rewrite, do it in an incremental way. Some of the ideas and fixes were good. Some, like xml configuration files, were bad and unpythonic. Even though the ideas behind it were good.

Configuration as such is good. It allows you to change things more easily. But don’t do it in xml files. But also watch out when doing it in python: you can easily get cyclic import conflicts. But if you do it right, you can combine and recombine configuration.

This “doing it right” was the basis for the grok project. It took ideas from rails and from django. Both offered a much friendlier face to the developers than zope did. With a couple of decorators they managed it. Check out Martian.

Sometimes Martijn gets a deja-vu from django. Zope is sometimes ahead in the future (like with unicode and class-based views). So he can give some messages from django’s future.

Watch out with dependencies. Make sure that in a big system, pulling in one part doesn’t automatically pull in everything else in one big tangled mess. Drop dependencies if you don’t need it.

Django doesn’t have packages, but the module level graph is pretty big and scary. He did some by-hand checking of the django code on the django.subpackage level. Lots of circular imports! You could not distribute django.views seperately if you’d want. It pulls in everything.

Is cleaning this up a good idea? Could you split up django? Would you want to? Would you want to split out django.db? Would you want to be able to replace or swap parts of django? Or upgrade one part separately? And… do you want other people to reuse individual bits of django? Like the orm? Or do you want a repeat of the jinja2-scenario?

Zope DID split things up, partially with the hope that other python developers would grab bits and pieces of zope. The success is mixed. Some parts are re-used, others aren’t hardly touched.

The most important outcome to zope is we’re less insular, more connected to python-as-a-whole. And zope suffers less from the not-invented-here syndrom.

And Not Invented Here is a danger. It can lead to a lack of reuse. And you learn less from others as you don’t look at other stuff anymore. If you read the django FAQ about the lack of reuse of generic packages the answer sounds to Martijn like “NIH NIH NIH NIH”.

Zope has invested a lot in integrating with python as a whole. WSGI. Python packaging. Lots of cross-pollination is happening. Lots of reuse. Less duplication. Using the best available libraries.

Your own code also becomes better if you turn it into a generic reusable libraries. And Martijn could then perhaps use cool django stuff without needing all of django.

Some libraries you might be interested in for reuse:

• Traject, it tries to combine object traversal with URL pattern matching. URL pattern matching to objects instead of to views, btw!

• Fanstatic (not “fantastic”). There’s django integration: https://bitbucket.org/fanstatic/django-fanstatic . A much simpler way to handle css/js dependencies. Resource bundling, smart cache invalidation and so.

• Obviel is a model/view/element system for client-side javascript. Build on jquery. Basically he brainstormed on using zope ideas for client side javascript, as a lot happens there nowadays. Restful json. It helps organize complex client-side applications into components. Good integration with client-side template systems.

If you want to check out some zope ideas: look at grok or at pyramid.