Chris McDonough wrote:
Note that the reason I suggested renaming Zope to "zope2" (or whatever) as
opposed to "zope" to "zope3" is because Zope 3 uses absolute imports almost
everywhere; it would be far less work to change "Zope" to "Zope2" because
Zope 2 either uses relative imports or assumes it can find what it needs on

Zope 3 is still (for a short time) in a far more plastic state. There aren't many third-party products and their authors expect change at this time. For example, we very recently rearranged the package.

> I think the breakage, although literally "incalculable" (as is
every change to Zope 2, given that it has no canonical API), would be
manageable given enough lead time.  In fact, if we did change the module
name, we could just leave a "bruce" package in place that, when imported,
raised a "ObsoleteError" with a descriptive message.

But I think that this is a big problem. Backward compatibility for Z2 *is* important. It's too bad that lots of test files have to import Zope. Sigh.

I *hate* the idea of having two packages named "zope" where case is the only
thing different.

Me too, the more I think about it.

> It's would be insanely difficult (not to mention
embarrassing) to document, should the two codebases merge in some unholy
fashion at some point as is on the 2.9 roadmap.

Actually, the Zope 2.8 roadmap. :) Zope 2.8 will have Zope 3 interfaces.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to