[Python-Dev] Relative Package Imports

[Gordon McMillan]

Jim Fulton wrote:

> It actually does now, although that is bad.  What if some future
> python distribution has a Products package? Or a Products.py?

Name it zopeProducts. Or Zope/Products and Zope/Shared.
 
> A product is actually a sub-package of Products. Even if Products
> was not a package, the Product would be and gadfly and kjParsong
> would be sub-packages.  There is a similar issue with Shared,
> since Shared software is organized by organization, as in
> 'Shared.DC.ZRDB'.

See below.
 
> The point is that stuffing arbitrary things into a single global
> name space is bad. That's why packages were invented.  Unless
> packages can be effectively nested, you haven't gained anything
> but time.

Packages nest effectively. Subpackages just don't 
masquerade as top level packages.
 
[Barry]
> > A
> > user would drop the kjParsing directory into Shared, and then
> > all the import kjParsing.kjParser statements would Just Work.
> 
> But then they'd be dumping kjParsing into the global package
> namespace. Eventually, there will be collisions.

You are trying to do two incompatible things at once. You are 
trying to be both a standalone application, and a Python 
installation. You can be both, just not at the same time.

To be a standalone application, you can use tricks that Jim 
Ahlstrom pointed out, or tricks from my Installer. The major 
point being that sys.path has nothing to do with the 
PYTHONPATH environment variable. You now have an 
installation where you can be assured of no collisions, 
because you control it completely.

Of course, that will make liars out of the people at your 
company who claim you can mix and match pieces of Zope 
and your own stuff as you please. People who want to mix 
and match need Zope to play by normal Python rules - and 
that means packages are installed at the top level. Collisions 
happen, but your audience is people who *want* to do things 
differently and *want* control of their installations.

By creating "self contained" packages and putting them in a 
normal Python installation, you're just pushing your headache 
off on the user. You're co-opting his installation.

Yeah, now you have two versions, but they're 99% the same. 
Build the normal Python one first and distribute it to the 
hackers. Then install some import and startup hooks, and 
distribute that to your "users".

I, for one, still use Bobo, because Zope doesn't play fair and I 
have no need or desire for yet another Python installation.

- Gordon