Re: [Python-Dev] Document None values in sys.modules?

On Fri, Jul 24, 2009 at 10:58, Guido van Rossum <guido@xxxxxxxxxx> wrote:

On Fri, Jul 24, 2009 at 10:50 AM, Brett Cannon<brett@xxxxxxxxxx> wrote:
>
>
> On Fri, Jul 24, 2009 at 10:39, Guido van Rossum <guido@xxxxxxxxxx> wrote:
>>
>> 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. :-)
>
> =) Yes, the None raising ImportError semantics can be added easily and
> codified as official import semantics in 3.1.

I thought it was too simple. :-) Maybe I should go back to bed and
nurse my cough some more instead of playing hookie from being sick and
indulging in email.

I'm glad I can help provide a distraction. And I hope you get over whatever you have soon.

Â

> I was talking about the "None
> triggers another import as with relative imports" semantics and if there was
> some rather convoluted way to trigger that.

I can't think of one and doubt you will find one -- it was introduced
(in the earliest of early package import implementations) to optimize
the problem we had with code living inside a package trying to stat()
a toplevel module locally each time an import of it was processed (a
problem if a package contains lots of modules each of which import os,
sys, etc.). Since we no longer to relative import, I don't see how
there could be another use -- if it's not there it's not there.

> I am guessing not as that would
> require a value of -1 for level which is no longer valid.

Ah. Sure.

> I will fix importlib in both 3.2 and 3.1.1. And speaking of fixing, should I
> put the failing test in now and decorate it with unittest.expectedFailure
> until I get around to fixing it?

Oh, I don't know. All this new-fangled technology... Can't you just
leave it in your workspace, unsubmitted, until you get to fixing it?

Oh sure, I normally just leave it in my scratch svn checkout until I get around to it. But since we now have the decorator I was wondering if any discussion came up while I was gone of using it within our testsÂwhenÂweÂhappenÂtoÂgetÂaÂworkingÂ(failing)ÂtestÂcaseÂbeforeÂweÂhaveÂaÂpatchÂtoÂfixÂit.

-Brett

_______________________________________________
Python-Dev mailing list
Python-Dev@xxxxxxxxxx
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/maillists%40codeha.us