[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