What do you tink of a package named "z"? (was Re: [ZODB-Dev] Re: Python module namespace pollution)

[Chris McDonough]

On Tue, 2004-04-20 at 05:57, Jim Fulton wrote:
> 2. I want to try out the "z" name on a wider audience. We want people to find
>     lots of Zope software usable outside of Zope. And I'm wondering if the use
>     of a name like "z" for a container package would affect someone's decision
>     about whether or not to use something in the package. I understand John's
>     reaction to the "z". Claiming a single letter is a bit bold. But as I
>     said in my other note, the leter "z" is already closely associated with Zope
>     in the Python community and it seems very unlikely that someone else would
>     want to use it.  (It's far less likely that someone would name a module
>     "z" than it is that someone would name a module "persistent" or "transaction".

One reason that Zope 2 is opaque to a lot of people is because it's not
always clear where the dependencies between packages are supposed to
align.  I think that it's more important to spread the word that Zope
3's constituent packages, whether or not they are rooted in a common
namespace and whatever the name of that namespace is, should be (are?)
as much as possible usable independently from the rest of the stuff that
resides in/along with that namespace.  This is more important than the
name of the namespace, I think.

I think the fact that we want them to all reside in a common namespace
is for purely technical reasons: we don't want name conflicts with the
stdlib or 3rd party packages.  The danger of the common namespace is
unclear dependencies: it's easy to assume that everything in "z" is
allowed to depend implicitly on everything else that might be in "z". 
Hopefully Fred's dependency work in the package tools makes this
explicit, but it's still a valid risk I think.

I wonder if it would be reasonable to try to have several top-level
namespaces (as opposed to just a single monster namespace) to make
thinking about dependency groups a bit easier?  For example, maybe there
should be a top-level "zodb" namespace that contains all the packages
that fall into the dependency graph of the packages that would be needed
to run ZODB independently from Zope?

Admittedly this has no real technical benefit, as it would be just as
valid to put the package into "zope.zodb", but it might have a positive
social impact, as I wonder if people could more easily mentally
disambiguate zope and zodb if the zodb package name wasn't always
referenced via "zope.zodb" or "z.zodb".

Other top-level candidates: "zdaemon", "pagetemplate",
"documenttemplate", "transaction", "interface", etc.  I realize this
extends the potential for name collisions, but it might make things a
little easier for people who are familiar with Python but new to Zope to
assume some of the maintenance burden of the packages if they were
grouped/rooted along dependency lines.  I dunno.  Just a suggestion.

- C