[Python-Dev] PEP 382 progress: import hooks (original) (raw)

P.J. Eby pje at telecommunity.com
Fri Jul 23 18:54:33 CEST 2010

At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote:

On Thu, Jul 22, 2010 at 19:19, P.J. Eby <<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:

What does "is not a package" actually mean in that context?

The module is a module but not a package.

Um... that's not any clearer. Are you saying that a module of the same name takes precedence over a package? Is that the current precedence as well?

Regarding loadmodulewithpath(), how does its specification differ from simply creating a module in sys.modules, setting its path, and then invoking the standard loadmodule()? Â (i.e., is this method actually needed, since a correct PEP 302 loader must reuse an existing module object in sys.modules)

It must reuse the module itself but a proper reload would reset path as leaving it unchanged is not a proper resetting of the module object. So this module is needed in order to force the loaderÂ

Um, no. Reloading doesn't reset the module contents, not even path. Never has, from Python 2.2 through 2.7 -- even in 3.1. At least, not for normal filesystem .py/.pyc files. (I tested with 'os', adding an extra 'foo' attribute, and also setting a path; both were unaffected by reload(), in all 7 Python versions.

Perhaps you're saying this happens with zipfiles, or packages that already have a path, or...?

Â

Am I correct in understanding that, as written, one would have to redefine import to implement this in a library for older Python versions? Â Or is it implementable as a metapath importer?

Redefine import (unless Martin and I are missing something, but I tried to think of how to implement this use sys.metapath and couldn't come up with a solution).

I'm thinking it could be done with a meta_path hook, but only by doubling the search length in the event that the search failed. That seems a bit icky, but replacing the entire import process seems ickier (more code surface to maintain, more bug potential) in the case of supporting older Pythons.

More information about the Python-Dev mailing list