[Zope-dev] Top-level namespace package for Zope 2 ?

Baiju M mbaiju at zeomega.com
Thu Dec 31 01:09:42 EST 2009


On Tue, Dec 29, 2009 at 6:51 PM, Hanno Schlichting <hanno at hannosch.eu> wrote:
> On Tue, Dec 29, 2009 at 2:10 PM, Baiju M <mbaiju at zeomega.com> wrote:
>>    I was going through Zope 2 source code today. There are 20+ top-level
>> packages specific to Zope 2.  Would it be useful if we move those packages
>> to a top-level namespace package.  I mean something similar to:
>> "zope.app.*", "grokcore.*", "repoze.bfg.*"  ?
>
> What would be the advantage of that? It'd break every single existing
> import. Most of those packages aren't reusable in the wild and
> shouldn't be released outside of the Zope2 distribution.
>
> 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.  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 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".

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 ?

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

 - Some of the things mentioned in this blog by Martin Aspelli:
   http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces

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

Regards,
Baiju M


More information about the Zope-Dev mailing list