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
sys.path.
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 zope.app 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
-- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
