[Python-Dev] Document None values in sys.modules?
Guido van Rossum
guido at python.org
Fri Jul 24 19:39:53 CEST 2009
Still works, at least in some old 3.1 I had lying around:
$ python3.1
Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['string'] = None
>>> import string
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named string
>>>
$ python3.1
Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import string
>>>
$
The experiment should be easily repeatable. :-)
--Guido
On Thu, Jul 23, 2009 at 8:35 PM, Brett Cannon<brett at python.org> wrote:
>
>
> On Thu, Jul 23, 2009 at 20:18, Guido van Rossum <guido at python.org> wrote:
>>
>> So, I guess, we'll live with it for a while longer. Given that it
>> managed to evade our attention for so long, I think that's fine.
>
> Can someone double-check me that the semantics can even be triggered in 3.1?
> I just tried and couldn't come up with anything. Heck, I quick search for a
> Py_None comparison in 3.1's import.c turned up nothing useful (other than
> mark_miss() is the function used to set None in sys.modules). We might have
> actually already removed it or made it so that the semantics can't be
> triggered.
>
>>
>> I agree that there's no reason for a None result from loaders to be
>> interpreted the same way, assuming that's not how it works ATM.
>>
>> And we can live with import and importlib differing on this in 3.1
>> (though you could call it a bug in importlib and fix it for 3.1.1 --
>> not sure if you were planning on that).
>
> I can if people can trigger the semantics somehow so I have a test to go by.
> -Brett
>
>>
>> --Guido
>>
>> On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon<brett at python.org> wrote:
>> >
>> >
>> > On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson <benjamin at python.org>
>> > wrote:
>> >>
>> >> 2009/7/23 Brett Cannon <brett at python.org>:
>> >> >
>> >> >
>> >> > On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson
>> >> > <benjamin at python.org>
>> >> > wrote:
>> >> >>
>> >> >> 2009/7/23 Brett Cannon <brett at python.org>:
>> >> >> > None in Python 3.1 is really useless in terms of its semantics in
>> >> >> > relative
>> >> >> > imports; importlib doesn't support it and still passes as
>> >> >> > __import__
>> >> >> > (at
>> >> >> > least last time I ran the test suite that way). I thought we had
>> >> >> > agreed
>> >> >> > a
>> >> >> > while back that supporting None was not warranted in Python 3.0?
>> >> >> > Otherwise I
>> >> >> > will do whatever work is necessary for this to happen.
>> >> >>
>> >> >> I think it's still nice for the rare cases where you need to trick a
>> >> >> module into thinking another one doesn't exist.
>> >> >
>> >> > But None does not strictly mean "I don't exist". None is supposed to
>> >> > trigger
>> >> > an another import attempt for the module with a top-level name. It's
>> >> > that
>> >> > extra import trigger that has no real use in 3.0 and just complicates
>> >> > import
>> >> > semantics (IMO) needlessly. If you want a module to not exist then
>> >> > you
>> >> > either stick something else in (e.g. '42') or we remove the special
>> >> > semantics for None (which I thought we had).
>> >>
>> >>
>> >> I didn't realize None had other semantics attached to it. (Imagine
>> >> that dealing with import!) +1 for making it simply indicate an
>> >> ImportError.
>> >
>> > I'm +0 with having import raise ImportError if None is set in
>> > sys.modules as
>> > long as we don't suddenly expect loaders to trigger the same thing if
>> > they
>> > return None (actually, as of right now what loaders return count for
>> > nothing, but just want to be clear).
>> > -Brett
>>
>>
>>
>> --
>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list