On Jun 15, 2006, at 3:13 AM, Philipp von Weitershausen wrote:
We've had two ZPT implementations, now we have to maintain only
had our own logging framework, now we can simply use Python's, etc.
These changes may seem cosmetic to the outside developer (he has to
different APIs), but they're essential to us as to how much code we
to have maintained or, in the worst case, bitrotting in our source
I'll note that even the outside developer may benefit from our using
more standard libraries, because they might already been known to him.
Even more so, they're already documented by someone else. (Was zLOG
documented? I don't think so. But the 'logging' module is.)
The zLOG removal will break far more third-party code than any other
API change we've talked about so far. The cost of each API change
needs to be weighed against its benefit. This is one of those cases
where backwards compatibility was free; the code was already there.
zLOG was just a tiny shim that called into the logging module.
Removing it is gratuitous. In general, this change is the definition
For what it's worth, maybe there's some middle ground here. Just
because something is deprecated doesn't need it needs to have a hard
date to be removed. Why don't we just have the first use of zLOG in
each module generate a deprecation warning and just leave it there
forever? People will get sick of seeing the warnings, and they'll
eventually change it, but there's just no reason to *force* them to
change it on our time schedule. And if they don't, who cares?
People who don't want to see the warnings can filter them out.
I'm also for reducing duplication, but only to the point that it does
not large amounts of break running code. We have yet to see what the
real fallout of changing to the Z3 ZPT implementation is. It may be
a pure win, but I wouldn't declare victory just yet, at least until
we have some empirical evidence that it doesn't break large existing
* moving to more Zope 3 technology.
We've managed to introduce Zope 3 technology in a couple of isolated
areas in Zope 2, e.g. i18n, views, object events. So far, we've only
seen deprecation warnings in the field of events where the old
methods have been deprecated. Zope 3's event system is superior to the
methhod overriding in Zope 2, hence we're evolving Zope 2. People
to use Zope 3 technology in Zope 2 more and more and currently the
framework it's stopping them in many ways. Five, on the other hand, is
just a (very large by now) compatibility layer (with lots of code
duplication) to which the first point shall also apply: we should
make code in Five smaller by evolving Zope 2.
There are reasons we are bothering to change the Zope 2 APIs at this
point instead of all of us moving to Zope 3 wholesale. One reason is
because we've figured out that in the real world backwards
compatibility and familiarity are primary drivers for take-up of
technology. Let's please not forget that again, and let's be careful.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -