[Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.108,1.109

[Guido van Rossum]

> 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 *".

> 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.

> 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.

--Guido van Rossum (home page: http://www.python.org/~guido/)