I know that many core devs subscribe to the new tracker issues list. If you skipped over http://bugs.python.org/issue19335 because it was (mis) titled as an Idle issue (as I presume most would), you might want to reconsider as it is actually a code and in particular, a codeop issue. Consider the real interpreter. C:\Programs\Python33>python Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def a(): ... def b(): ... nonlocal c ... _ <blinkin> It waits to see if one enters a blank line (to which it properly responds SyntaxError), or continues with something that makes the statement syntactically valid. ... c = 1 ... >>> The 'close simulation' in the code module acts differently. C:\Programs\Python33>python -m code Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> def a(): ... def b(): ... nonlocal c File "<string>", line None SyntaxError: no binding for nonlocal 'c' found It prematurely acts as if one had entered a fourth, blank line. InteractiveConsole subclasses InteractiveInterpreter (as does Idle, hence the same behavior). II.runsource compiles with codeop.CommandCompile, which wraps codeop._maybe_compile, which returns None (src incomplete), raises (src complete and bad), or returns code (complete and ok) to be executed. For the above code, it re-raises SyntaxError instead of returning None. The issue needs someone who can find and read the C equivalent used by the real interpreter. Perhaps the latter was adjusted when nonlocal was introduced, while codeop was not. -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4