Packages & __path__ (was:Re: [Python-Dev] Python 2.3a1 release -- Dec 31)

Samuele Pedroni pedronis@bluewin.ch
Thu, 26 Dec 2002 01:14:30 +0100


From: "Just van Rossum" <just@letterror.com>
> > Both solutions are OK, and yes the 2nd simplifies some things.
>
> Hey, a consensus ;-)

between the 2 of us, yes, let's wait what the others have to say.
Deprecating __path__ is maybe a small vs big change but is a subtle one.

> > My only remaining worry, once the above is sorted out, is whether the
> > PEP302 scheme can be in the future expanded to support ihooks like
> > functionalities (like those used by Quixote) in a non-messy way.
>
> Right now there are two ways to go about addressing the issue:
>
> A) turn/wrap the builtin Path importer into a real object on
> sys.meta_path.
>
> B) create a subset of ihooks.py as a new module (written in Python),
> reimplementing some of the path import logic.
>
> Either one should provide an API for adding file type handlers. (I'm not
> so sure ihooks even provides a straightforward way for multiple
> independent packages to each add their own file type handlers. For
> example I don't see how Quixote could currently be compatible with other
> packages doing similar things, short of chaining __import__ hooks. A new
> solution should have it as a major goal to make this possible.)
>
> B could be a prototype for A, so it seems logical to initially go for B.
> This doesn't (IMO) need to be in first alpha, so there's more time to
> experiment and discuss.

my view-point:

when you bring ihooks-type functionality in the picture, I see the following
separation of concerns:

- opaque importers:  fullname  -> module
- other importers:

* the importers allow to fish for file-like objects of some types
(corresponding to file extensions in filesystem-like cases)

* there is a way to register new types and way to convert file-like objects
into code/modules.

instead of asking directly for a module, one would ask the importer
for <fullname>[.__init__] and  e.g. types  (module,code,source (py), bytecode
(pyc), plt, pltc)

[module and code are special types ]

the importers would return some proxies for all relevant objects, the proxies
would allow to possibly "open" and "read" the object and will present an
optional timestamp.

The converters would be used to make code/modules out of the objects.

regards.