[Python-3000] Changing the import machinery

Guido van Rossum guido at python.org
Fri Apr 21 11:42:37 CEST 2006


On 4/20/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> I'm afraid I disagree.  PEP 302 actually has some tremendous advantages
> over a pure objects-on-sys.path approach:
>
> * Strings can be put in any configuration file, and used in .pth files
>
> * Strings can be put in environment variables (like PYTHONPATH).
>
> * Strings can be printed out, with all their contents showing and nothing
> hidden
>
> In short, strings are better for humans.

I think I like this. I wonder if there's a parallel with my preference
for strings as paths instead of path objects...

> There are only two things wrong with PEP 302 IMO, and neither is its "fault".
>
> The first is that the "classic" import machinery isn't on sys.meta_path,
> and the 'imp' API isn't defined in terms of PEP 302.  Those two things
> can't change without introducing backward incompatibilities.

So it's  a perfect py3k project.

> The second is that PEP 302 only covers "location" importers, not "format"
> importers.  That is, if you want to do something like make Kid or Cheetah
> templates importable, you have to replace things with new machinery.  This
> is a more important problem to solve, IMO, than coming up with yet another
> set of semantics for the things that *are* covered by PEP 302.
>
> PEP 302 is reasonably clear and concise, although there are occasional
> loopholes.  At least three people have re-implemented parts of it in pure
> Python from the spec: Just van Rossum, Neal Norwitz, and myself (twice, in
> my case).  It is easy and elegant -- the only hard parts are when you have
> to wedge all the "classic" imports in, or if you want to implement "format"
> importers.
>
> So, my vote for Py3K is to move the classic import machinery to explicit
> objects on sys.meta_path -- preferably one for each distinct rule, so that
> it is possible to *remove* them if you don't want them.  (For example, the
> Chandler folks have made a big deal about not wanting general Windows
> registry imports to apply; it would be nice if they could just delete an
> object from sys.meta_path rather than having to build their own Python to
> elide this.)

+1

> I would also suggest that we ask Just if he can come up with some elegant
> extension that would allow PEP 302 to support pluggable import *formats* as
> well as locations.  :)

I guess you'll need to explain this particular problem a bit better...

--
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list