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/)