[Zope3-dev] Voting on Schema design

[R. David Murray]

On Mon, 15 Jul 2002, Shane Hathaway wrote:
> Zope 3 will have even more reusable packages.  Therefore Zope 3 uses a
> top-level package called Zope, but the top-level package functions only
> as a *namespace*.  This is very similar to Java's package naming
> convention, but we're not using an "org" prefix.

I think the theory is understood.  I think the question is about
whether or not there is a need for this.

> Thus the presence of, say, Zope.ComponentArchitecture, does not imply
> the presence of Zope.PageTemplate, even though both are distributed with
> Zope.  Nor should Zope.PageTemplate expect to find
> Zope.ComponentArchitecture.  Developers will be able to select only the
>   parts they need from Zope.*, while at the same time, installing Zope
> won't flood site-packages.

I personally don't see "flooding" site-packages as an issue.  I
have no problem with seeing a large number of packages/modules in
there.  But what you are really saying is that name space collisions
*are* an issue, which is why I'm willing to (reluctently) go along
with it.  But pretty much only because I'm hopeful that the Python
community is going to grow so large that we have to worry about
name space collisions <grin>.

I'd almost rather PythonLabs set up some sort of name registry.

"Zope", by the way, *is* an org prefix, if you look at it sideways.

Although, to answer Martijn's question as to what goes in lib/python
as opposed to lib/python/Zope, I have an "easy" answser to that
one.  IMO, the stuff that goes in lib/python is the stuff that
someday wants to be part of the Python batteries-included library.
I'd like Schema to be in that category <grin>.

Which brings up one of the big disadvantages of the 'Zope'
namespace scheme.  It makes it impossible to promote a package
into the batteries-included library.  And that would be a shame.

--RDM