February 10, 2010
Carlos de la Guardia has written a book on Grok, a Python web framework I helped kick off and contributed to quite a lot. I was honoured to be asked to write the foreword for it. Here’s what I wrote:
A little less than a year ago, Zope 4 was released. As the successor of the complex, verbose and certainly not agile Zope 3 (now called BlueBream), it was instantly welcomed with much cheer. Naturally I chimed in and announced without much hesitation that the forthcoming 4th edition of my book would already be based on lean and mean Zope 4.
Sadly these were all just April fool’s jokes.
Sadly? No, I should say luckily. Because something much better came out of Zope land just a few months after we jokingly invented a new Zope version. Grok 1.0 was released. And thanks to Carlos’ tremendous effort, there’s now a book to accompany and celebrate this achievement, too.
There is much to say about this book, but I’m sure you’re eager to get started with your web application. So let me just tell you what I like best about it.
Carlos has managed to capture the Grok spirit in this book. It is concise, not too heavy and doesn’t beat about the bush. Yet it manages to hit all the bases of web development. With a spikey club, of course. It is as smashing as the framework itself and I hope you’ll enjoy both as much as I have.
February 3, 2010
Chris McDonough has written a book on repoze.bfg! repoze.bfg, or simply BFG, is a web framework written in Python. It’s of Zope pedigree but borrows many ideas from Pylons and Django as well. It’s simple yet powerful, agile, fast, has close to 100% test coverage and is extremely well documented.
Most importantly, however, BFG is true to its motto “pay only for what you eat.” You can use SQLAlchemy, Zope’s object store ZODB, or some other persistence mechanism. You can use Zope-style object traversal, Routes-style URL mapping or a combination of both. You can use Zope Page Templates, Genshi (both through the extremely fast Chameleon engine), Jinja, or your favourite templating language. You can write your application in an extensible manner using declarative configuration, or you can just use the Python API. You can deploy on Google App Engine, Apache and mod_wsgi or anywhere else that supports WSGI. And you needn’t worry about learning about the stuff you’re not using.
January 14, 2010
Attention, attention! This is a service announcement!
I haven’t been blogging much about Python and Zope lately. In fact, as some of you may have noticed, I’m no longer involved in Zope at all. I continue to use Python, though. To keep your feed aggregators a.k.a. planets topical I suggest removing my blog feed from Zope related planets and switch Python related aggregators to my Python category feed.
If any of you readers have found my blog through one of the Python and Zope planets and still enjoyed my other posts, I suggest adding my general feed to your news reader so you continue to get updates. Thank you.
End of service announcement.
April 1, 2009
I know people have been eagerly waiting for an updated version of my Zope 3 book, Web Component Development with Zope 3. While the first edition targeted Zope 3.0, the second and third are targetting Zope 3.3, a release that is several years old now. Since then, Zope 3 technologies like the Component Architecture have equally found adoption among the Plone project and hatred among the rest of the Python web developers. Time then for an update of the most popular Zope book, right?
There were some original plans to base the fourth edition on Grok, the upstart project within the Zope world. With its developer-friendly attitude and pragmatism, it seemed like a viable path out of the Zope 3 complications. With the advent of Zope 4, however, this has completely changed. Zope 4 certainly makes Grok look old and used. Grok is so 2008 now. That’s why I’m happy to announce that the next edition of my book will target Zope 4:
I’m also happy to announce that the book will be available soon! Writing the 4th edition really was a breeze, thanks to Zope 4’s completely non-enterprisey approach, the adoption of interfacelets (which allow you to write the generally disliked Zope interfaces with much less code in much less time), and the automatic componentizer which turns any Spaghetti code (e.g. a Django webapp) into nice reusable components. Zope 4 also fixes some mistakes that were made in Zope 3, for instance by bringing back proven Zope 2 technologies such as DTML and Acquisition. This sped up the writing of the 4th edition tremendously as well, as I was able to simply cobble the relevant chapters together from all those $4.99 Zope 2 books on Amazon.
Right now I’m just finishing the last chapter. It’s about the Zope Stallion, a feature that was introduced to compete with the Django Pony. After this it shouldn’t take long for the book to go into print. I think Amazon will even be taking your preorders soon, so act … uhm … soon!
September 17, 2008
Mark Ramm’s keynote at DjangoCon, A TurboGears guy on what Django could learn from Zope, has made the rounds in the Python blogosphere this week. His main point is that other projects will always have more talented people than your project. That’s why it’s always a good idea to be open, share technology and work with others. The real point, however, is that you can learn from each other’s mistakes (and he specifically advises Django to not repeat Zope’s mistakes).
This brings me to an interview with Scott Collins, published by Ars Technica in July 2004 (sic!). When asked about the mistakes Mozilla had made in the past, one of the things he mentions seems awfully familiar:
We made a version of COM, called XPCOM, a fundamental piece of every component of every part of the software. We took COM all the way down to the lowest levels of the system, and I think that XPCOM is a fantastic useful tool. We had great and important places to use it, but we used it too deeply, we allowed it to influence our memory model across the board, and there continue to be costs associated with that which I don’t think we need to be paying. I feel bad that I let it go that deep when I continually fought against it, but I am one of the perpetrators — I wrote some of the machinery that made it easy to use COM, and that allowed people to go deeper and deeper, which we knew was a mistake.
I’ve been saying this for years, and people tend to think that I’m damning COM unconditionally, and I’m not. COM is very important to us, and it’s a foundation of our scriptability layer, and scriptability is fundamental to how our application works. But I don’t think every object should be a COM object. We are finally moving away from using COM for everything, and maybe a synergy with Mono will help us get to the right level of differentiation between objects. This is a deep engineering thing, but I believe that fundamentally that we took the COM metaphor too deep and we paid a price for that: we could have more performance sooner earlier on if we had recognized and stuck to limits in our use of COM.
Most of this statement would hold true for Zope if you replaced “COM” with “Component Architecture”, even the bit about the speed. I’m not saying that the CA is slow, but it’s making us write stuff in complicated ways which seems to end up slowing down everything as a whole. Not to mention developer speed and developer learning speed. We had to build a whole framework on top of Zope just to hide the complexity of the CA for beginners.
Mozilla has learnt its lesson and refactored its code, especially the Gecko rendering engine. I wouldn’t be surprised if the speed and memory improvements in Firefox versions 2 and 3 are in part due to reducing the overuse of XPCOM. If you now think Zope hasn’t learnt its lesson yet, it’s not quite true. The Repoze guys have taken great ideas from Zope and re-implemented them in a much simpler manner that doesn’t need the Component Architecture and works well with others (by [ab]using WSGI) and makes them scale incredibly well. Examples:
- repoze.tm2, a WSGI middleware that allows application-wide transactions (an alternative to having the transaction handling mangled into the object publisher)
- repoze.who, a WSGI middleware for authentication (an alternative to Zope’s
- repoze.urispace, an implementation of W3 URISpace which describe a method to define arbitrary application policy based on URL paths (an alternative to Zope 2’s acquisition and Zope 3’s local components)
- repoze.errorlog, repoze.profile, repoze.debug, etc., which are various WSGI middlewares that take responsibility out of the object publisher
This isn’t to say that the Component Architecture isn’t useful or elegant because it is. But after having spent nearly two years helping create a framework that tries to hide the complexity of CA (over)use, I think it’s time to change gears a bit. The Repoze guys have pioneered it, now it’s time that Zope itself embraced it. If I were to pick, the publisher, its publication machinery and the traversal code would be the first to undergo this treatment, and Martijn seems to have those on his list as well. But Zope is bigger than just the two of us.
From my mailinglist post:
When relying on a third-party package with ZCML configuration, it is sometimes desirable to disable certain directives, for instance when the third-party package defines an event subscriber that you’d like to disable. This is now possible with z3c.unconfigure.
While zope.configuration (the package that implements ZCML) itself supports overriding existing configuration and the zc.configuration package supports excluding whole ZCML files from being loaded, z3c.unconfigure allows you to disable specific directives.
More information is available at http://pypi.python.org/pypi/z3c.unconfigure.
August 1, 2008
I apologize in advance if I’m stealing anybody’s thunder with this post, but why should we keep it a secret that ME GROK HAS DOKS! Much thanks to Uli Fouquet for setting up the reference docs using Sphinx!
July 19, 2008
The release process that I wrote for the Zope subversion repository states that a library’s version number on the trunk or a release branch should always be the next release version number applicable to that branch. For instance, if
zope.interface 3.4.1 were just released from the 3.4.x branch, the version number of
zope.interface on that branch should read 3.4.2dev.
Let me explain why I suggested this practice and, despite much critique, still maintain it’s makes the most sense.
First of all, the setuptools documentation states:
Note: the project version number you specify in setup.py should always be the next version of your software, not the last released version.
So it’s a convention that seems to be generally suggested. That doesn’t necessarily mean it’s a good idea, though.
What makes it a good idea is the fact that when you get a checkout of the trunk or a development branch, the version number is actually meaningful, due to setuptools’ version semantics
3.4.1 < 3.4.2dev < 3.4.2
So, a development egg of
zope.interface 3.4.2dev will for instance satisfy a version requirement like “
zope.interface > 3.4.1“. For example, say you wanted to temporarily deploy from a subversion checkout. I had to do this to get my PyFlakes running with Emacs. The latest release PyFlakes 0.2.1 wasn’t good enough because something got fixed on the trunk. So I got a trunk checkout and did a
python setup.py install
into a virtualenv. Surely enough, the trunk’s version number was still pointing to 0.2.1. So I ended up with
pyflakes-0.2.1-py2.4.egg in my site-packages and no way to tell it from the actual 0.2.1 release. (Yes, I know there’s some setuptools parameter than can let you build versions like 0.2.1-r48292, and those would be fine, if they were configured to occur on the trunk automatically.) So that’s why not only bumping the version number to the next release but also adding the “
dev” marker to tell development eggs or snapshots apart from actual release (and prevent people from releasing from the trunk!) is a good idea.
To conclude, I think bumping the version number to the next or at least the next anticipated release (it’s ok if you don’t get the version number right the first time) and adding a dev marker is not only a good idea, I think it’s pretty much the only way to get the version number semantics of development eggs right (unless you use r34234 suffixes which have other problems). Of course, I’m willing to be convinced otherwise if alternate solutions achieve the same semantics. Comment away!