Marc-Andre wrote:
Fredrik Lundh wrote:
Guido van Rossum <guido@CNRI.Reston.VA.US> wrote:
- suggestions for new issues that maybe ought to be settled in 1.6
three things: imputil, imputil, imputil
But please don't add the current version as default importer... its strategy is way too slow for real life apps (yes, I've tested this: imports typically take twice as long as with the builtin importer).
I think imputil's emulation of the builtin importer is more of a demonstration than a serious implementation. As for speed, it depends on the test.
I'd opt for an import manager which provides a useful API for import hooks to register themselves with.
I think that rather than blindly chain themselves together, there should be a simple minded manager. This could let the programmer prioritize them.
What we really need is not yet another complete reimplementation of what the builtin importer does, but rather a more detailed exposure of the various import aspects: finding modules and loading modules.
The first clause I sort of agree with - the current implementation is a fine implementation of a filesystem directory based importer. I strongly disagree with the second clause. The current import hooks are just such a detailed exposure; and they are incomprehensible and unmanagable. I guess you want to tweak the "finding" part of the builtin import mechanism. But that's no reason to ask all importers to break themselves up into "find" and "load" pieces. It's a reason to ask that the standard importer be, in some sense, "subclassable" (ie, expose hooks, or perhaps be an extension class like thingie). - Gordon