Baiju M wrote:

>> The packages that we might want to break out (like we did with
>> Acquistion, ExtensionClass, DateTime) should retain their name, so
>> nobody has to change any code to work with them.
> I think we could have added those packages in a namespace.

Why? A million things depend on these with the names they have now. 
Inventing a new namespace for the sake of a new namespace and asking all 
those applications to change their code is to be obsessive-compulsive.

 > What if we want
> to extract similar things out of Zope 2 core.  For example DTML related
> things could be extracted out of Zope 2 core.

I doubt there is much stuff there that anyone other than Zope 2 cares 
about. Even Acquisition and ExtensionClass are dubious. There's already 
a DTML implementation in somewhere.

> I guess we are planning to improve the WSGI story of Zope 2,
> in addition to creating new packages, we will be required to re-factor
> existing code for this.  I hope these kind of "refactoring" would be much
> easier with namespace packages. One of the major contributing factor why
> we were able to create a nice ZTK out of Zope 3 is the use of "namespace".

Mmm... I doubt that. Any module path change is painful. The WSGI story 
exists in repoze.zope2 and just needs to be officially blessed if we 
want that. I don't see that this has anything to do with re-organising 
legacy code that's been there for nearly a decade.

> There are few more important factors:
>    - We should not clutter top-level names with Zope 2 specific packages
>      This is very important in the context of new distribution mechanism
>      we adopted (egg, PyPI). Courtesy to other PyPI users ?

I agree in general, but we are unlikely to have many new packages. Note 
that we can name eggs whatever we want, without using namespace 
packages. Yes, if someone wanted to use Zope 2's Acquisition in Django 
and Django had a module called Acquisition that would clash. If you find 
someone who wants to do that, or anything like it, slap them. They'll 
thank you later.

>   - Branding Zope technologies is also very important. Yes, Zope
>     is still a good brand :)

We are doing that with dozens of zope.* packages. If we really are 
refactoring things out of Zope 2, they should go into existing/new 
zope.* packages. We don't need a new namespace.

>   - Some of the things mentioned in this blog by Martin Aspelli:

*cough* *Aspeli* *cough* :)

> PEP 20: "Namespaces are one honking great idea -- let's do more of those!"

They're not such a good idea that we should arbitrarily cause people 
pain just to have them. Zope 2 is very old. We have to accept that some 
things (like namespace packages or setuptools) just didn't exist when 
its architectural decisions were taken.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See

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

Reply via email to