[Python-Dev] Relative Package Imports

[Jim Fulton]

"James C. Ahlstrom" wrote:
> 
> Jim Fulton wrote:
> > In this context, consider the following concrete, though fictional
> > example.
> > ............
> 
> The classical solution would be to add "Shared" to sys.path.  But
> how to do this?  And what if another installation changes it?

This doesn't work, because 'Shared' has sub-packages by organization.

> > I'd be curious to hear how folks would solve this problem.
> 
> 1) Ship a custom binary interpreter with critical modules frozen in,
> and which sets a custom sys.path before anything else happens.  So
> you are not dependent at all on PYTHONPATH.  Currently this works.

This is what we do for our binary distribtions, but it doesn't do
anything for third-party products added to Zope.

> 2) Add a new command line option which sets sys.path and always use
> it to start your app.  It lists only critical zope directories so
> zope has its own private name space.

We have a start script that takes care of this.  This gets Zope's 
top-level names (of which there are too many already) into the
path.  This doesn't help with third-party products added to Zope.
 
> 3) Add your own import hooks using imputil.py and boot it as
> in (1).

But imputil has a global effect. I suppose I could implement
what I want with imputil or by otherwise creating my own importer
using the standard import hooks.  I suspect that's what I'll
have to do eventually.

>  Better if it were part of Python. 
> 4) Use a new Python.pyl file which has seeking from the end and
> thus allows concattenation of multiple *.pyl.  Each package is
> a foo.pyl, bar.pyl, and to distribute an app, you concatenate
> packages.  The implied PYTHONPATH in each *.pyl file is "."
> except perhaps for the Python lib which is "Lib".  Boot it as
> in (3).

I'm not looking for a way to replace the current package scheme.
Also, I'm not just looking at an app, but at an app that
contains apps (aka components).
 
> > Personally, I'd like the problem to go away. :)
> 
> I have the same problem, so me too.
> 
> > I'd like the Python
> > import rules to change to make this solvable without import hooks or
> > path hacking.  I can think of two ways to approach this:
> >
> >   - Relative parent imports:
> >
> >       import __.kjParsing.kjParser
> 
> OK by me, but doesn't solve the Grand Problem.
> 
> >   - Gradually less local searches.
> 
> I am currently bewildered by Python's import mechanism, and
> this may push me into brain damage.  Well, *more* brain damage.

I don't see what's so complicated.  You just use a gradually
widening search, rather than an immediately widening search.
I don't think that this is any more complicated than the current
rule.

I actually prefer the second apprach because it doesn't require any
code changes to take advantage of it.  I may implement it for Zope
if nothing is done in standard Python.

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.