[Python-Dev] Undocumented PEP 302 protocol change by need-for-speed sprint

[Brett Cannon]

On 7/20/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>
> At 12:28 PM 7/20/2006 -0700, Brett Cannon wrote:
> >On 7/20/06, Phillip J. Eby
> ><<mailto:pje at telecommunity.com>pje at telecommunity.com> 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".


Ah.  Sounds like None is not really even needed  with the change (although I
am not suggesting the removal of None).

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().
>
>
Well, I have not played with the PEP 302 stuff so I don't know how helpful
they are to have around.  But it is definitely a semantic change that either
needs to be reverted or documented.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060720/61ed8b42/attachment.html