At 12:28 PM 7/20/2006 -0700, Brett Cannon wrote:
>On 7/20/06, Phillip J. Eby 
><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote:
>>While investigating the need to apply 
>><http://python.org/sf/1525766>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?
>
>Revert it.  Is it really that much of a bonus to use False over 
>None?  Both evaluate to false and both are already singleton so you can 
>use 'is' for testing.

The changed code still uses None.  PEP 302 defines None as meaning that a 
sys.path entry does not have an importer.  It's just that the 
need-for-speed patch *adds* the use of True and False.  None still means 
"no importer", but True now means "no importer, path exists" and False now 
means "no importer, path does not exist".

The idea is that import.c can then skip checking the existence of the path 
when it sees True or False, but it then means that code that gets data from 
path_importer_cache needs to know about these new special values, or else 
it will get an attribute error when it tries to call True.find_module().

_______________________________________________
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/archive%40mail-archive.com

Reply via email to