PEP 382 progress: import hooks
At EuroPython, I sat down with Brett and we propose an approach how namespace packages get along with import hooks. I reshuffled the order in which things get done a little bit, and added a section that elaborates on the hooks. Basically, a finder will need to support a find_path method, return all .pth files, and a loader will need to support a load_module_with_path method, to initialize __path__. Please comment if you think that this needs further changes; I'll hope to start implementing it soon. Regards, Martin
At 01:51 PM 7/22/2010 +0100, Martin v. Löwis wrote:
At EuroPython, I sat down with Brett and we propose an approach how namespace packages get along with import hooks. I reshuffled the order in which things get done a little bit, and added a section that elaborates on the hooks.
Basically, a finder will need to support a find_path method, return all .pth files, and a loader will need to support a load_module_with_path method, to initialize __path__.
Please comment if you think that this needs further changes;
I'm not certain I understand it precisely. There seem to be some ambiguities in the spec, e.g.: "If fullname is not found, is not a package, or does not have any *.pth files, None must be returned." What does "is not a package" actually mean in that context? What happens if an empty list is returned - does that mean the importer is saying, "this is a package, whether it has an __init__.py or not?" As for the "list of strings" returned, is each string the entire contents of the .pth file? Is it to be \n-separated, or is any universal-newlines-compatible string accepted? Is there a particular order in which .pth file contents are to be returned? Regarding load_module_with_path(), how does its specification differ from simply creating a module in sys.modules, setting its __path__, and then invoking the standard load_module()? (i.e., is this method actually needed, since a correct PEP 302 loader *must* reuse an existing module object in sys.modules)
I'll hope to start implementing it soon.
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 meta_path importer?
Regards, Martin
Thanks for your work on this, I was just thinking about pinging to see how it was going. ;-) (I want setuptools 0.7 to be able to supply an add-on module for supporting this PEP in older Pythons, so that its current .pth hacks for implementing namespace packages can be dropped.)
On Thu, Jul 22, 2010 at 19:19, P.J. Eby <pje@telecommunity.com> wrote:
At 01:51 PM 7/22/2010 +0100, Martin v. Löwis wrote:
At EuroPython, I sat down with Brett and we propose an approach how namespace packages get along with import hooks. I reshuffled the order in which things get done a little bit, and added a section that elaborates on the hooks.
Basically, a finder will need to support a find_path method, return all .pth files, and a loader will need to support a load_module_with_path method, to initialize __path__.
Please comment if you think that this needs further changes;
I'm not certain I understand it precisely. There seem to be some ambiguities in the spec, e.g.:
"If fullname is not found, is not a package, or does not have any *.pth files, None must be returned."
What does "is not a package" actually mean in that context?
The module is a module but not a package.
What happens if an empty list is returned - does that mean the importer is saying, "this is a package, whether it has an __init__.py or not?"
As for the "list of strings" returned, is each string the entire contents of the .pth file? Is it to be \n-separated, or is any universal-newlines-compatible string accepted? Is there a particular order in which .pth file contents are to be returned?
Regarding load_module_with_path(), how does its specification differ from simply creating a module in sys.modules, setting its __path__, and then invoking the standard load_module()? (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
I'll hope to start implementing it soon.
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 meta_path importer?
Redefine __import__ (unless Martin and I are missing something, but I tried to think of how to implement this use sys.meta_path and couldn't come up with a solution). -Brett
Regards,
Martin
Thanks for your work on this, I was just thinking about pinging to see how it was going. ;-)
(I want setuptools 0.7 to be able to supply an add-on module for supporting this PEP in older Pythons, so that its current .pth hacks for implementing namespace packages can be dropped.)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
On 7/23/2010 11:57 AM, Brett Cannon wrote:
On Thu, Jul 22, 2010 at 19:19, P.J. Eby <pje@telecommunity.com <mailto:pje@telecommunity.com>> wrote:
At 01:51 PM 7/22/2010 +0100, Martin v. Löwis wrote:
At EuroPython, I sat down with Brett and we propose an approach how namespace packages get along with import hooks. I reshuffled the order in which things get done a little bit, and added a section that elaborates on the hooks.
Basically, a finder will need to support a find_path method, return all .pth files, and a loader will need to support a load_module_with_path method, to initialize __path__.
Please comment if you think that this needs further changes;
I'm not certain I understand it precisely. There seem to be some ambiguities in the spec, e.g.:
"If fullname is not found, is not a package, or does not have any *.pth files, None must be returned."
What does "is not a package" actually mean in that context?
The module is a module but not a package.
so s/is not a package/is a module rather than a package/ perhaps? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
participants (4)
-
"Martin v. Löwis"
-
Brett Cannon
-
P.J. Eby
-
Steve Holden