[Import-SIG] PEP 402 implementation
brett at python.org
Wed Jul 20 23:55:38 CEST 2011
No specific reason. Feel free to file a bug and assign it to me.
On Wed, Jul 20, 2011 at 14:15, P.J. Eby <pje at telecommunity.com> wrote:
> At 01:08 PM 7/20/2011 -0700, Brett Cannon wrote:
>> Obviously feel free to ask me questions (publicly or privately) if
>> anything in the importlib code is an issue for you (I know its structure for
>> bootstrapping reasons is a bit odd).
> While we're on the topic, I was just browsing through importlib (while
> doing my sketch on how to support the "no pure virtual imports" change to
> PEP 402; see http://mail.python.org/**pipermail/python-dev/2011-**
> July/112385.html<http://mail.python.org/pipermail/python-dev/2011-July/112385.html>) and I noticed that there are a few places in the implementation where it
> makes assumptions about objects' boolean values.
> For example, PathFinder's find_module treats an empty path the same as
> sys.path, and will also fail if for some reason the bool() of a PEP 302
> finder or loader object is False. Also, module_for_loader() will create a
> new module object, if you have a False module subclass in sys.modules.
> Is there any particular reason for these digressions from strict PEP 302?
> I can understand, say, Jython and IronPython not wanting to generate object
> id's, but I was under the impression that those languages can do identity
> checks (especially against None) without running into the general problem of
> generating object IDs in the presence of garbage collection.
> These distinctions could be more problematic than they appear, as it's
> possible to inadvertently make your loader or your module subclass capable
> of being False (for example, if you subclassed a sequence type or
> implemented a __len__), and this could lead to some very subtle bugs, albeit
> very rare ones as well. ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Import-SIG