On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon<
brett@python.org> wrote:
>
>
> On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson <
benjamin@python.org>
> wrote:
>>
>> 2009/7/23 Brett Cannon <
brett@python.org>:
>> >
>> >
>> > On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson <
benjamin@python.org>
>> > wrote:
>> >>
>> >> 2009/7/23 Brett Cannon <
brett@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