[Python-Dev] Relative Package Imports

[Jim Fulton]

Gordon McMillan wrote:
> 
> Jim Fulton wrote:
> 
(snip)
> Packages nest effectively. Subpackages just don't
> masquerade as top level packages.

They do currently when imported from the containing package.

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

We don't try to be a Python installation.  We try to be a
Python application that is a platform for Zope applications.
 
> 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.

Zope reuses *alot* of code. I think Zope has a pretty
good track record of working with existing code.

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

Sorry, I just don't buy that.

> Collisions
> happen, but your audience is people who *want* to do things
> differently and *want* control of their installations.

Actually, many Zope user's come to Python by way of Zope.
They want to be able to install Zope products without
worrying about what their zope or python installation 
looks like.

Zope developers want to be able to have their products drop
into a Zope installation easily.
 
> 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.

No, putting packages in the python path coops their installation.
Putting Zope-specific products that happen to include reusable
Python packages in a Zope-specific package leaves their 
installation alone.

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

This is exactly what I want to prevent. I'd like package 
developers to develop their packages once without making them
use esoteric import hooks. OTOH I'd like to be able to *use*
their packages wherever I damn well please. I don't to be forced
to put their packages in the python path.
 
> I, for one, still use Bobo, because Zope doesn't play fair

In what way does Zope not play fair?

> and I
> have no need or desire for yet another Python installation.

Cool. You don't need to use another Python installation to use Zope.
In fact, for development, we use a totally standard Python distribution.
Developers here are not *allowed* to add anything special to the 
Python installations on the development machines here because we want to
*make sure* that we can run with stock python installations.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.