-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Codeop: Show warnings once during _maybe_compile #84984
Comments
When calling See msg370163 and that issue for context. |
The purpose of code and codeop is to imitate interactive python in python. Calling compile() thrice is an implementation detail. Exposing that is a bug. On bpo-37824, Serhiy reported 3 'IDLE' bugs for 3.7 to 3.9: tripled DeprecationWarning (now joined by SyntaxWarning), printing to console (if available) instead of Shell, and an exit exception. This issue is continuation of the triplicate issue, given that the bug is not in IDLE. As a bug, I think it should still be backported. I looked more carefully at the behavior of the standard REPL with different statement inputs. Before executing, if the statement is complete, it may raise a compile exception, usually SyntaxError, or emit one or more a warnings, once for each instance. For multiline statements, DeprecationWarnings are emitted immediately after the line with the deprecated code while SyntaxWarnings are emitted, if there is no syntax error, just before execution. SyntaxWarnings for a given slice of code are not repeated. However, at least some of these details have to be enforced in the UI code that repeatedly calls compile or _maybe_compile as lines are added, not in compile, and should not be in _maybe_compile. Both have no memory or previous calls. (I don't think that IDLE necessarily *must* do the same either.) Looking at compile itself, it appears that warnings are not emitted if there is an exception. But I am puzzled at this in 3.9 and master. >>> if '\e' is 1:
<stdin>:1: DeprecationWarning: invalid escape sequence \e
...
versus
>>> compile('if '\e' is 1:\n', '', 'single')
File "<stdin>", line 1
SyntaxError: unexpected character after line continuation character Something must cause "'\e'" to be a warning instead of an error. This is enough to experiment with your patch applied. |
I am not sure if 3 compiles are always needed. At one time, compile required a final '\n' to not raise, but that is no longer true. And as near as I can tell, 'code without final newline\n' and 'code without final newline\n\n' always compile the same. Certainly, Shell does not need to compile without a final newline. But we can look at this in a separate issue. If IDLE's requirement is different from code.II's, I believe it could pass its own compile function. |
This is a spinoff of bpo-37824. My above comments about compile are wrong. The example nests '' within ''. And, with freshly compiled master, I found an example where Deprecation warning, but not SyntaxWarning, accompanies SyntaxError, and which requires trailing \n. >>> compile("if'\e' is 1: 1", '', 'single')
DeprecationWarning...
SyntaxError: unexpected EOF while parsing
>>> compile("if'\e' is 1: 1\n", '', 'single')
DeprecationWarning...
SyntaxWarning...
<code object ...>
Interactively,
>>> if'\e' is 1: 1
<stdin>:1: DeprecationWarning: invalid escape sequence \e
...
<stdin>:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
>>> In IDLE, DeprecationWarning is repeated, but that is another issue. The secondary prompts seems like a bug, The statement is complete and entering anything but a comment is a SyntaxError. (A comment results in another ... prompt.) |
The 3.7 backport is needed but required a revised example. The changeset is 4b378ac. PRs 20486, 20639, 20672, and 20673 are the main patch. PRs 20646 and 20647 for 3.8 and 3.7 backport a test_codeop import change made elsewhere and not backported. The alternative would have been changing our backport to the older naming convention. |
I think that might have introduce https://bugs.python.org/issue41520 where now |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: