[Python-Dev] Undocumented PEP 302 protocol change by need-for-speed sprint (original) (raw)

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