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 former was planned for implementation in the realease following basic 302 support (and I don't see any potential compatibility issues). I just never got round to actually doing that, probably having to do with the fact that hacking import.c stops being "fun" after a while... I appreciate you defending PEP 302, it's pretty neat. However, I'm not convinced that we need all that much flexibility. Back then it seemed to satisfy most people's needs, while still keeping maximum compatibility. Still it may be somewhat overengineered. The original idea of simply allowing importer-ish objects on sys.path (or just callables) may be feasible for p3yk, although I would really like to see import semantics to be simplified. Eg. after all those years I still don't like pkg.__path__ at all. I proposed to kill back in the forming days of PEP 302, but was unable to convince Guido. Not sure if it's smart to try again four years later :) Whatever we end up with, I think it would be a tremendous win if we could implement most of the import logic in Python. Phillip: I'm not sure what "format importers" are or do. Can you give an example of how you'd use those? Just _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
