(Looking for
Homebrew Encryption?)
I can feel his pain. This is why code generation sucks, and persistent stale code is evil. This is one reason that Webware's reloading is so nice.
Interesting factoid: Zope 3 (last time I heard) won't reload your files for you, you have to restart the server. Presumably manually. Unfortunately, the Zope server can't be restarted anywhere close to fast enough to make Webware's technique work (Webware starts fast enough that it can restart on a whim, like when any file is edited). Jim Fulton seemed uncomfortable with Zope 2's product reloading, mostly because of these evil stale code issues that come up occassionally.
Zope 2's "product reloading" is optional, conditioned on a flag that you put in a file within your product. I never use it, just because it's easy enough to press "ctrl-C, up-arrow, enter" on the console I use to run Zope (and it only takes about 10 seconds or so for it to restart). You get used to it. I won't miss it in Zope 3.
I add the usual comment: in Common Lisp or Smalltalk based web apps you
can do live updates that immediately update all current instances, including
nifty update schemes to old instances if necessary. If your Zope server restarts
in ten seconds consider yourself lucky, on a large site with many products and
lots of content it takes a bit more. I'd rather have live updates without any
delay. It enables a more explorative style of development. Even a small delay
like ten seconds is painful in interactive work -- imagine if the Python CLI
took a ten second for each expression...
Smalltalk has an easier time of it because it doesn't have to keep source in a file in sync with code in the process. Non-product (through-the-web) Zope development, where code is kept in the ZODB (similar to the Smalltalk image) doesn't have this syncing problem. I've never had problems with stale code in that environment. OTOH, that environment sucks for all sorts of other reasons, and Smalltalk isn't immune to those same issues. (All the past criticisms of Smalltalk I wrote in http://blog.colorstudy.com/ianb/weblog/2004/03/10.html#P68 apply quite well to Zope in this respect)
However, I certainly concede that it's a compromise -- there are real advantages to the way Smalltalk does it. (Frankly, the Zope through-the-web environment isn't mature enough to stand up nearly as well to these criticisms.) But those advantages are closely tied to some disadvantages. (Well, if Python modules and classes were more declarative and less imperative, it would be possible to do these updates a bit more elegantly -- but that itself is a compromise, as there's some added flexibility in Python because of the concreteness of its objects.)# Ian Bicking
Nils: I think the problem with your Zope restarts might be that you don't use ZEO. With ZEO, restarts are quite fast as the database index never needs be rebuilt (unless you stop the ZEO server in an unorderly fashion). The number of products doesn't really impact things significantly (unless you have an ill-behaved product, that is).
In any case, needing to restart the process that rusn my code really doesn't bother me very much (Zope or non-Zope), as long as it takes under, say, 10 seconds. The only time I really want to see changes immediately is for presentation/HTML code, which, in Zope, CMF skins allow me to do, and for CGI/mod_*, obviously just happens anyway (with extreme penalties and with some caveats).
Chris: the site I was talking about uses ZEO. It is just very large with lots of render clients. It's also not a good fit for Zope because Zope wasn't designed for building a distributed transaction platform. And the folks who wrote the original code were worse developers than monkeys on crack.
# Nils Kassube