On Fri, Jul 24, 2009 at 10:58, Guido van Rossum <gu...@python.org> wrote:
> On Fri, Jul 24, 2009 at 10:50 AM, Brett Cannon<br...@python.org> wrote: > > > > > > On Fri, Jul 24, 2009 at 10:39, Guido van Rossum <gu...@python.org> > 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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
