Turns out IDLE no longer runs. Starting at line 88 of Tools/idle/EditorWindow.py we have this class defn: class EditorWindow: from Percolator import Percolator from ColorDelegator import ColorDelegator from UndoDelegator import UndoDelegator from IOBinding import IOBinding import Bindings from Tkinter import Toplevel from MultiStatusBar import MultiStatusBar about_title = about_title ... This leads to what looks like a bug (if we're to believe the error msg, which doesn't mean what it says): C:\Pyk>python tools/idle/idle.pyw Traceback (most recent call last): File "tools/idle/idle.pyw", line 2, in ? import idle File "C:\PYK\Tools\idle\idle.py", line 11, in ? import PyShell File "C:\PYK\Tools\idle\PyShell.py", line 15, in ? from EditorWindow import EditorWindow, fixwordbreaks File "C:\PYK\Tools\idle\EditorWindow.py", line 88, in ? class EditorWindow: File "C:\PYK\Tools\idle\EditorWindow.py", line 90, in EditorWindow from Percolator import Percolator SyntaxError: 'from ... import *' may only occur in a module scope Hit return to exit... C:\Pyk> Sorry for the delay in reporting this! I've had other problems with the Windows installer (all fixed now), and IDLE *normally* executes pythonw.exe on Windows, which tosses error msgs into a bit bucket. So all I knew was that IDLE "didn't come up", and took the high-probability guess that it was due to some other problem I was already tracking down. Lost that bet.
Tim Peters wrote:
I have already reported this to Jeremy. There are other instances of 'from x import *' in function and class scope too, e.g. some test() functions in the standard dist do this. I am repeating myself here, but I think that this single change will cause so many people to find their scripts are failing that it is really not worth it. Better issue a warning than raise an exception here ! -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
[M.-A. Lemburg]
But there are no instances of "from x import *" in the case I reported, despite that the error msg (erroneously!) claimed there was. It's complaining about from Percolator import Percolator in a class definition. That smells like a bug, not a debatable design choice.
Provided the case above is fixed, IDLE will indeed fail to compile anyway, because Guido does from Tkinter import * inside several functions. But that's a different problem.
Better issue a warning than raise an exception here !
If Jeremy can't generate correct code, a warning is too weak.
Tim Peters wrote:
Percolator has "from x import *" code. This is what is causing the exception. I think it has already been fixed in CVS though, so should work again.
How is it different ? Even though I agree that "from x import *" is bad style, it is quite common in testing code or code which imports a set of symbols from generated modules or modules containing only constants e.g. for protocols, error codes, etc.
Better issue a warning than raise an exception here !
If Jeremy can't generate correct code, a warning is too weak.
So this is the price we pay for having nested scopes... :-( -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Percolator has "from x import *" code. This is what is causing the exception.
Woo hoo! The traceback bamboozled me: it doesn't show any code from Percolator.py, just the import in EditorWindow.py. So I'll call *that* the bug <0.7 wink>.
I think it has already been fixed in CVS though, so should work again.
Doesn't work for me. If someone does patch Percolator.py, though, it will just blow up again at from IOBinding import IOBinding . Guido was apparently fond of this trick.
I know I'm being brief, but please don't take that as disagreement. It's heading on 6 in the morning here and I've been plugging away at the release for a loooong time. I'm not in favor of banning "from x import *" if there's an alternative. But I don't grok the implementation issues in this area well enough right now to address it; I'm also hoping that Jeremy can, and much more quickly.
Better issue a warning than raise an exception here !
If Jeremy can't generate correct code, a warning is too weak.
So this is the price we pay for having nested scopes... :-(
I don't know. It apparently is the state of the code at this instant. sleeping-on-it<0.1-wink>-ly y'rs - tim
Tim Peters wrote:
For completeness, here are all instance I've found in the standard dist: ./Tools/pynche/pyColorChooser.py: -- from Tkinter import * ./Tools/idle/IOBinding.py: -- from Tkinter import * ./Tools/idle/Percolator.py: -- from Tkinter import *
Ok, Good Night then :-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
MAL> Better issue a warning than raise an exception here ! TP> If Jeremy can't generate correct code, a warning is too weak. MAL> So this is the price we pay for having nested scopes... :-( TP> I don't know. It apparently is the state of the code at this TP> instant. The code is complaining about 'from ... import *' with nested scopes, because of a potential ambiguity: def f(): from string import * def g(s): return strip(s) It is unclear whether this code intends to use a global named strip or to the name strip defined in f() by 'from string import *'. It is possible, I'm sure, to complain about only those cases where free variables exist in a nested scope and 'from ... import *' is used. I don't know if I will be able to modify the compiler so it complains about *only* these cases in time for 2.1a2. Jeremy
Jeremy Hylton wrote:
The right thing to do in this situation is for Python to walk up the nested scopes and look for the "strip" symbol.
Since this is backward compatible, wouldn't it suffice to simply use LOAD_GLOBAL for all nested scopes below the first scope which uses from ... import * ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
MAL> Even though I agree that "from x import *" is bad style, it is MAL> quite common in testing code or code which imports a set of symbols MAL> from generated modules or modules containing only constants MAL> e.g. for protocols, error codes, etc. In fact, the entire exercise of making "from x import *" obey __all__ when it's present is to at least reduce the "badness" of this bad style. Skip
"TP" == Tim Peters <tim.one@home.com> writes:
TP> Provided the case above is fixed, IDLE will indeed fail to TP> compile anyway, because Guido does TP> from Tkinter import * TP> inside several functions. But that's a different problem. That will probably be the most common breakage in existing code. I've already `fixed' the one such occurance in Tools/pynche. gotta-love-alphas-ly y'rs, -Barry
Tim Peters wrote:
I have already reported this to Jeremy. There are other instances of 'from x import *' in function and class scope too, e.g. some test() functions in the standard dist do this. I am repeating myself here, but I think that this single change will cause so many people to find their scripts are failing that it is really not worth it. Better issue a warning than raise an exception here ! -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
[M.-A. Lemburg]
But there are no instances of "from x import *" in the case I reported, despite that the error msg (erroneously!) claimed there was. It's complaining about from Percolator import Percolator in a class definition. That smells like a bug, not a debatable design choice.
Provided the case above is fixed, IDLE will indeed fail to compile anyway, because Guido does from Tkinter import * inside several functions. But that's a different problem.
Better issue a warning than raise an exception here !
If Jeremy can't generate correct code, a warning is too weak.
Tim Peters wrote:
Percolator has "from x import *" code. This is what is causing the exception. I think it has already been fixed in CVS though, so should work again.
How is it different ? Even though I agree that "from x import *" is bad style, it is quite common in testing code or code which imports a set of symbols from generated modules or modules containing only constants e.g. for protocols, error codes, etc.
Better issue a warning than raise an exception here !
If Jeremy can't generate correct code, a warning is too weak.
So this is the price we pay for having nested scopes... :-( -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Percolator has "from x import *" code. This is what is causing the exception.
Woo hoo! The traceback bamboozled me: it doesn't show any code from Percolator.py, just the import in EditorWindow.py. So I'll call *that* the bug <0.7 wink>.
I think it has already been fixed in CVS though, so should work again.
Doesn't work for me. If someone does patch Percolator.py, though, it will just blow up again at from IOBinding import IOBinding . Guido was apparently fond of this trick.
I know I'm being brief, but please don't take that as disagreement. It's heading on 6 in the morning here and I've been plugging away at the release for a loooong time. I'm not in favor of banning "from x import *" if there's an alternative. But I don't grok the implementation issues in this area well enough right now to address it; I'm also hoping that Jeremy can, and much more quickly.
Better issue a warning than raise an exception here !
If Jeremy can't generate correct code, a warning is too weak.
So this is the price we pay for having nested scopes... :-(
I don't know. It apparently is the state of the code at this instant. sleeping-on-it<0.1-wink>-ly y'rs - tim
Tim Peters wrote:
For completeness, here are all instance I've found in the standard dist: ./Tools/pynche/pyColorChooser.py: -- from Tkinter import * ./Tools/idle/IOBinding.py: -- from Tkinter import * ./Tools/idle/Percolator.py: -- from Tkinter import *
Ok, Good Night then :-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
MAL> Better issue a warning than raise an exception here ! TP> If Jeremy can't generate correct code, a warning is too weak. MAL> So this is the price we pay for having nested scopes... :-( TP> I don't know. It apparently is the state of the code at this TP> instant. The code is complaining about 'from ... import *' with nested scopes, because of a potential ambiguity: def f(): from string import * def g(s): return strip(s) It is unclear whether this code intends to use a global named strip or to the name strip defined in f() by 'from string import *'. It is possible, I'm sure, to complain about only those cases where free variables exist in a nested scope and 'from ... import *' is used. I don't know if I will be able to modify the compiler so it complains about *only* these cases in time for 2.1a2. Jeremy
Jeremy Hylton wrote:
The right thing to do in this situation is for Python to walk up the nested scopes and look for the "strip" symbol.
Since this is backward compatible, wouldn't it suffice to simply use LOAD_GLOBAL for all nested scopes below the first scope which uses from ... import * ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
MAL> Even though I agree that "from x import *" is bad style, it is MAL> quite common in testing code or code which imports a set of symbols MAL> from generated modules or modules containing only constants MAL> e.g. for protocols, error codes, etc. In fact, the entire exercise of making "from x import *" obey __all__ when it's present is to at least reduce the "badness" of this bad style. Skip
"TP" == Tim Peters <tim.one@home.com> writes:
TP> Provided the case above is fixed, IDLE will indeed fail to TP> compile anyway, because Guido does TP> from Tkinter import * TP> inside several functions. But that's a different problem. That will probably be the most common breakage in existing code. I've already `fixed' the one such occurance in Tools/pynche. gotta-love-alphas-ly y'rs, -Barry
participants (5)
-
barry＠digicool.com -
Jeremy Hylton -
M.-A. Lemburg -
Skip Montanaro -
Tim Peters