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

[Jim Fulton]

Chris McDonough wrote:
> 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.

Sure.

> 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.

It's a valid risk, but:

- The README.txt file in the zope package goes out of it's way to
   say that, except for app, the packages there should be usable outside of
   Zope and should have mimimal interdepencencies.

- As you point out, fred's work will introduce dependency files that
   document and *constrain* dependencies.  They will help to make
   explicit and enforce and conntrol the dependencies amoung packages.

> 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?

I think dependencies are a poor basis for organizing the package structure.
Dependencies are too dynamic. Changing a dependency should not force a
change in the package structure, I think this would provide too much package
structure.

> Admittedly this has no real technical benefit,

And even do harm. :)

 > 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".

I'm very hopeful and fairly confident that the dependency files
will have the same social benefit without unduly affecting package
structure.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org