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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4