
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/

"M.-A. Lemburg" wrote:
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

"M.-A. Lemburg" wrote:
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
participants (2)
-
James C. Ahlstrom
-
M.-A. Lemburg