Sat, 18 Nov 2000 13:58:49 +0100
Greg Stein wrote:
> [ restricting to the import-sig ]
> On Fri, Nov 17, 2000 at 05:45:58PM +0100, M.-A. Lemburg wrote:
> > Thomas Heller wrote:
> > > imputil, which is now an official part of
> > > python, changes the semantics of sys.path
> > > as soon as importers are installed.
> > >
> > > On the other hand, a quick and dirty search
> > > finds at least these files in the standard library
> > > where it is assumed that sys.path is a list of strings:
> > >
> > > linecache.py, profile.py, pdb.py, pyclbr.py
> > >
> > > Should imputil be fixed to install the ImportManager
> > > in a different way (not installing the importers
> > > into sys.path), or should the library be fixed?
> > My understanding was that Importers need to provide
> > a __str__ method which is then used... haven't looked
> > at imputil.py in ages though, so I can't really comment.
> > Perhaps imputil.py should leave sys.path alone (or maybe just
> > wipe it from unneeded entries) and use a new sys.importers
> > object for the import management ?!
> Guido didn't like that approach (which I had suggested at one point). He
> wanted all the stuff to appear in sys.path, and for other code to "just
But sys.path is about OS level path names... perhaps we ought to
reconsider this ?!
After all, it would allow easy checking of whether there is
enhanced import management in place or not and sys.path could
even be reused in some way by these importers in some way.
AFAIR, there was no general agreement on how to redesign
the import mechanism. Maybe what we need is not a redesign,
but instead an extensible way to extend the import mechanism...
take for example the codec registry design: instead of
pushing some sort of package layout on the codec packages,
the packages can register a search function which then
implements whatever lookup is needed.
A similar approach could help adding new import mechanisms
to Python without ripping out the existing support.
Python Pages: http://www.lemburg.com/python/