[Python-Dev] Undocumented PEP 302 protocol change by need-for-speed sprint
Phillip J. Eby
pje at telecommunity.com
Thu Jul 20 20:57:07 CEST 2006
While investigating the need to apply http://python.org/sf/1525766 I found
that there was a modification to pkgutil during the need-for-speed sprint
that affects the PEP 302 protocol in a backwards incompatible way.
Specifically, PEP 302 documents that path_importer_cache always contains
either importer objects or None. Any code written to obtain importer
objects is therefore now broken, because import.c is slapping False in for
non-existent filesystem paths.
The pkgutil module was then hacked to work around this problem, thereby
hiding the breakage from at least the standard library, but not any
external libraries that follow the PEP 302 protocol to find importers.
There are several options as to how to proceed:
1. Revert the change
2. Document the breakage, update PEP 302, and make everybody update their code
3. Make it not break existing code, by using a NonexistentPathImporter or
NullImporter type in place of "False" in sys.path_importer_cache.
Any thoughts?
Personally, the only code I know of that implements the PEP 302 protocol
besides the pkgutil module that would be affected is pkg_resources in
setuptools, so it's not like I can't fix it for 2.5.
However, I don't know if anybody else is using the protocol, and if so, how
bad the breakage would be. This should really only affect code that is
walking sys.path, because paths with "False" in sys.path_importer_cache by
definition cannot have any importable modules associated with them. So,
although I don't like option 2 on general principles, it may be an
acceptable solution.
More information about the Python-Dev
mailing list