[Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.108,1.109
Tue, 30 Jan 2001 16:52:04 +0100
On Tue, Jan 30, 2001 at 10:06:57AM -0500, Guido van Rossum wrote:
> > On Mon, Jan 29, 2001 at 05:27:30PM -0800, Jeremy Hylton wrote:
> > > add note about two kinds of illegal imports that are now checked
> > > + - The compiler will report a SyntaxError if "from ... import *" occurs
> > > + in a function or class scope or if a name bound by the import
> > > + statement is declared global in the same scope. The language
> > > + reference has also documented that these cases are illegal, but
> > > + they were not enforced.
> > 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:
> > Is there really a reason to enforce this, or are we enforcing the
> > wording of the language reference for the sake of enforcing the
> > wording of the language reference ? When writing 'import as' for
> > 2.0, I fixed some of the inconsistencies in import, making it adhere
> > to 'global' statements in as many cases as possible (all except
> > 'from ... import *') but I was apparently not aware of the wording
> > of the language reference. I'd suggest updating the wording in the
> > language reference, not the implementation, unless there is a good
> > reason to disallow this.
> 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
And I also want to be able to do:
if with == 1:
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
And I can't quite argue that away with 'the compiler needs to know ...' --
it's all there!
> > 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.
Thomas Wouters <firstname.lastname@example.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!