[Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.108,1.109
Guido van Rossum
Tue, 30 Jan 2001 15:42:58 -0500
> > > Woah. Is this really a good idea ? I have seen 'from ... import *'
> > > in a function scope put to good (relatively -- we're talking 'import
> > > *' here) use. I also thought of 'import' as yet another assignment
> > > statement, so to me it's both logical and consistent if 'import'
> > > would listen to 'global'. Otherwise we have to re-invent 'import
> > > spam; eggs = spam' if we want eggs to be global.
> > Note that Jeremy is only raising errors for "from M import *".
> No, he says he's also raising errors for 'import spam' if 'spam' is declared
> global, like so:
> def viking():
> global spam
> import spam
Yeah, this was just brought to my attention at our group meeting
today. I'm with you on this one -- there really isn't a good reason
why this shouldn't work. (I wonder why that constraint was ever added
to the reference manual; maybe I was just upset that someone would
*do* something as ugly as that, or maybe there was a J[P]ython
> > I think Jeremy has an excellent reason. Compilers want to do analysis
> > of name usage at compile time. The value of * cannot be determined at
> > compile time (you cannot know what module will actually be imported at
> > run time). Up till now, we were able to fudge this, but Jeremy's new
> > compiler needs to know exactly which names are defined in all local
> > scopes, in order to do nested scopes right.
> Hrrmm.... I guess I have to agree with that. None the less, I wish we could
> have a "ack! this is stupid code! it uses 'from larch import *'! All bets
> are off, we do a lot of slow complicated runtime checking now!" mode. The
> thing I still enjoy most about Python is that it always does what I want,
> and though I'd never want to do 'from different import *' in a local scope,
> I do want other, less wise people to have the same experience, where
> possible :)
Hm, maybe, just *maybe* Jeremy can do this if there are no nested
scopes in sight. But I don't think it's a big deal as long as the
error message is clear -- it's bad style.
> And I also want to be able to do:
> def fill_me(with):
> global me
> if with == 1:
> import me
> elif with == 2:
> import me_too as me
> elif with == 3:
> from me.Tools import me_me as me
> elif with == 4:
> me = FakeModule()
> sys.modules['me'] = me
> raise ValueError
> And I can't quite argue that away with 'the compiler needs to know ...' --
> it's all there!
Sort of, although I would prefer to do a two-stager here: first some
variation of "import me as meohmy", and then "global me; me = meohmy" .
> > > I also have another issue with your recent patches, Jeremy, also in
> > > the backwards-compatibility departement :) You gave new.code two
> > > new, non-optional arguments, in the middle of the long argument
> > > list. I sent a note about it to python-checkins instead of
> > > python-dev by accident, but Fred seemed to agree with me there.
> > (Tim will love this. :-)
> > I don't know what those new arguments represent. If they can
> > reasonably be assumed to be empty for code that doesn't use the new
> > features, I'd say move them to the end and default them properly. If
> > they must be specified, I'd say too bad, the new module is an accident
> > of the implementation anyway, and its users should update their code.
> Okay, I can live with that. It's sure to cause some gripes though. Then
> again, from looking at the code I'd say those arguments (freevars and
> cellvars) can easily default to empty tuples.
OK. I hope Jeremy can fix this when he gets home.
--Guido van Rossum (home page: http://www.python.org/~guido/)