Mailing List Archive

Import Design
Before hooking on to some more PathBuiltinImporters ;-), I'd like
to spawn a thread leading in a different direction...

There has been some discussion on what we really expect of the
import mechanism to be able to do. Here's a summary of what I
think we need:

* compatibility with the existing import mechanism

* imports from library archives (e.g. .pyl or .par-files)

* a modified intra package import lookup scheme (the thingy
which I call "walk-me-up-Scotty" patch -- see previous posts)

And for some fancy stuff:

* imports from URLs (e.g. these could be put on the path for
automatic inclusion in the import scan or be passed explicitly
to __import__)

* a (file based) static lookup cache to enhance lookup
performance which is enabled via a command line switch
(rather than being enabled per default), so that the
user can decide whether to apply this optimization or
not

The point I want to make is: there aren't all that many features
we are really looking for, so why not incorporate these into
the builtin importer and only *then* start thinking about
schemes for hooks, managers, etc. ?!

--
Marc-Andre Lemburg
______________________________________________________________________
Y2000: 37 days left
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
Re: Import Design [ In reply to ]
"M.-A. Lemburg" wrote:

> The point I want to make is: there aren't all that many features
> we are really looking for, so why not incorporate these into
> the builtin importer and only *then* start thinking about
> schemes for hooks, managers, etc. ?!

Marc has made this point before, and I think it should be
considered carefully. It is a lot of work to re-create the
current import logic in Python and it is almost guaranteed
to be slower. So why do it?

I like imputil.py because it leads
to very simple Python installations. I view this as
a Python promotion issue. If we have a boot mechanism plus
archive files, we can have few-file Python installations
with package addition being just adding another file.

But at least some of this code must be in C. I volunteer to
write the rest of it in C if that is what people want. But it
would add two hundred more lines of code to import.c. So
maybe now is the time to switch to imputil, instead of waiting
for later.

But I am indifferent as long as I can tell a Python user
to just put an archive file libpy.pyl in his Python directory
and everything will Just Work.

Jim Ahlstrom