Phillip J. Eby wrote:
> 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.
>
> 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.
Do you mean an API so you can associate loader objects with new extensions,
allowing find_module and load_module to deal with them? A cleaned up
replacement for the current _PyImport_FileTab?
What about something like a sys.load_hooks list? The default contents of
sys.load_hooks (on Windows) would be:
PythonPackageLoader (handles directories with __init__.py files)
PythonDLLLoader (handles .pyd files)
PythonSourceLoader (handles .py and .pyw files, checks for compiled file)
PythonCompiledLoader (handles either .pyc and .pyo files, depending on -O)
That would let us get rid of a lot of ifdef hackery from import.c, and also
permit things like:
sys.load_hooks.append(ZipLoader)
where "ZipLoader" handles files ending in .zip or .egg, and treats them as
packages.
Putting "foo.zip" or "foo.egg" somewhere on sys.path would then allow "import
foo" and "from foo import bar" to work without requiring a path hook for every
module.
(Random aside: why the heck is all this machinery stored in sys, anyway?
Having it in imp would make far more sense. Was it just because sys.path was
already there?)
> 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.
Make that 4 - I had to reimplement a chunk of it for PEP 338. And as you say,
the only part that made it particularly hard was that the classic machinery
doesn't play by the rules.
Using PEP 302, the path importer cache ends up becoming the container with the
special objects for the benefit of the interpreter, while the original path
continues to contain the human-readable strings.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
