[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Terry J. Reedy added the comment: I reread Nick's comment "the C level loop simply blocks on stdin, waiting until the parser spits out a complete AST." I interpret that now as meaning that the REPL compiles user code only once per statement, which IDLE and code.InteractiveInterpreter

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Pablo Galindo Salgado added the comment: first case -> second case -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Pablo Galindo Salgado added the comment: > At least the fact that the SyntaxError message is some for both of Well, is the same because the semantics are the same: a symbol is missing in the expected scopes. The only difference is that in the first case is not even possible to "fix it"

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Lysandros Nikolaou added the comment: some -> same -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Lysandros Nikolaou added the comment: That's right, but the SyntaxError message is somewhat confusing. At least the fact that the SyntaxError message is some for both of def a(): def b(): nonlocal x and def a(): nonlocal x seems a bit misleading. No? --

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Pablo Galindo Salgado added the comment: >1) We should alter code in symtable.c to check whether the namespace in which >the nonlocal statement appears in is a function block and whether it is nested >or not. Also, the 'nesting' has very specific meanings in the symbol table: scoping. The

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Pablo Galindo Salgado added the comment: > 1) We should alter code in symtable.c to check whether the namespace in which > the nonlocal statement appears in is a function block and whether it is > nested or not. We already raise in this case. Consider this 'test.py' file: x = 34 def f():

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Lysandros Nikolaou added the comment: I feel that I wasn't clear at all in my previous responses, so let me try to have another go at explaining how I see this: We have two distinct problems, that are totally unrelated to one another: 1) nonlocal should raise when it's not in a nested

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Terry J. Reedy added the comment: _maybe_compile currently compiles the possibly complete statement up to 3 times -- with C-coded compile. Without doing any timing tests, I wondered if 3 times is really necessary. Nick suggested that using the tokenize module to determine the number of

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Rahul Jha added the comment: > Note that these are two solution that take very different approaches. What > Nick is suggesting with "checking for two or more hanging INDENTS" would > drastically change how codeop._maybe_compile does its thing, while his other > proposed solution,

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Lysandros Nikolaou added the comment: > From what I understand, "checking for two or more hanging INDENTS" and, > "hardcoding a check for nonlocal SyntaxErrors in codeop._maybe_compile" are > two different solutions, right? If yes, do we have an answer to which one of > them is more

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Rahul Jha added the comment: > That may actually be another alternative: instead of doing the "try > appending newlines and see if it works or generates different errors", > we may be able to switch to the tokenizer if the initial compilation > fails and check for hanging INDENT tokens (i.e.

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Lysandros Nikolaou added the comment: > If I understand correctly, Nick is talking about modifying the different > iterations for different errors in codeop no? I was talking about msg200936, where Nick proposed to just hardcode a check for nonlocal SyntaxErrors in codeop._maybe_compile,

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Pablo Galindo Salgado added the comment: > Pablo, correct me if I'm wrong, but I think that the parser has nothing to do > with this. It's not the parser that produces this SyntaxError, it's some > later compilation phase (I guess symtable creation phase?), which I know very > very little

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Lysandros Nikolaou added the comment: > What do either of you think? Can the new parser handle it better? Pablo, correct me if I'm wrong, but I think that the parser has nothing to do with this. It's not the parser that produces this SyntaxError, it's some later compilation phase (I guess

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Change by Matthias Bussonnier : -- nosy: +mbussonn ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Terry J. Reedy added the comment: Note: Recently in #40807, Cheryl and I patched codeop._maybecompile to only emits warnings once in a given call. I don't know if 3 calls (2 '\n' additions) to compile are really needed today. The logic that handles the results is not clear to me either.

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Terry J. Reedy added the comment: Pablo and Lysandros: this issue is about a corner-case bug in either compile(,,'single') or its use by REPL and codeop._maybe_compile (comc). What do either of you think? Can the new parser handle it better? Should we just add the hack suggested by Nick

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Change by Rahul Jha : -- nosy: +RJ722 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Esa Peuha added the comment: Someone needs to compare _maybe_compile to the equivalent C code used by the real interpreter. Well, _maybe_compile() just calls the built-in function compile() internally, so I'm not sure what sort of comparison you want... -- nosy: +Esa.Peuha title:

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Changes by Mark Shannon m...@hotpy.org: -- nosy: +Mark.Shannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19335 ___ ___ Python-bugs-list

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Nick Coghlan added the comment: The comment at the top of codeop explains the problem (and why Terry is interested in what the C code is doing, since it's clearly different): === Compile three times: as is, with \n, and with \n\n appended. If it compiles as is, it's complete. If

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Nick Coghlan added the comment: As a potential fix (albeit an ugly hack), try changing this part of codeop._maybe_compile: if not code1 and repr(err1) == repr(err2): raise err1 To something like: if not code1 and repr(err1) == repr(err2): if isinstance(err1,

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

R. David Murray added the comment: A complete fix is going to require setting a flag that we have a pending non-local, and check that flag when the code input is complete to raise the SyntaxError at that point if the non-local hasn't been set. -- nosy: +r.david.murray

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

Nick Coghlan added the comment: codeop compiles the whole pending statement every time, so that part shouldn't be needed (from the compiler's point of view, this input looks complete - there's nothing dangling, any more than there is for a normal syntax error like name name). As far as I can