Terry J. Reedy <tjre...@udel.edu> added the comment:
Treating a SyntaxWarning as an error is intentional, since 2001 in a Kurt
Kaiser patch. IDLE's ModifiedInterpreter subclasses
code.InteractiveInterpreter. The subclass .runsource turns a SyntaxWarning
into an error, before calling the superclass method, with
warnings.filterwarnings(action="error", category=SyntaxWarning)
As long as this is true, it should be documented. It is included in #37825.
In interactive python (as opposed to IDLE), code is executed after a
SyntaxWarning. In the non-callable call examples, minimally "()()", "[]()",
"1()", and "''()", the result is a traceback that repeats the warning message.
I think the repetition is mostly noise and is better omitted. I don't know what
SyntaxWarnings were present in 2001, but I presume that Kurt had the same
impression, whatever it or they were.
The non-callable calls violate the 'ideal' Python grammar, which would have a
production like "call = possible_callable '(', args, ')'. Violations are
caught by the compiler rather than the parser. But they could plausibly be
called a (subclass of) SyntaxError and execution avoided everywhere.
The situation is quite different with "literal is (not) something", where
'literal' includes constant tuples. The expression is valid, normally runs
without exception, and should be executed. To me, this is not a syntax issue,
so SyntaxWarning seems wrong. But as long as is used for this situation, the
conversion to error must cease. (If I knew how, I would prefer to still not
call known non-callables in Shell.)
There are two subcases with different reasons for pinging users.
1. The result is obvious ("0 is ''", "0 is ()") and unchanged when 'is' is
replaced with '=='. The advice is useless. It should instead, it seems to me,
be to use True or False. I suspect that this case is rare.
2. The result using 'is' is implementation dependent ("0 is 0", "0 is a", "1000
is 1000"). For production code, the advice to change 'is' to '==' is correct.
For exploration of 'is' in a shell, which many beginners like to do, it likely
is not, at least not immediately.
--
My initial messsage above is moot since compile("assert (0, 'bad')", '',
'single') no longer emit a SyntaxWarning, and the new warnings do not show the
same behavior, even for similarly legal code such as "0 is 0".
My second message, about when a SyntaxWarning for a file is displayed, is still
relevant, and I agree that it is a higher priority than before.
But it is more complex than reported above. First, there are other warnings
than SyntaxWarning, and we might decide to optionally enable them. Second, Run
Module does Check Module first. If Check Module is selected directly, there is
no restart line. Third, there will be no restart line if there is a
SyntaxError, or a Tabnanny but there might be prior warnings. I think I know
how to deal with all of the above.
Module SyntaxErrors and Tabnanny errors are displayed in a popup error box,
with the cursor moved to the line and maybe column of the error. Warnings
could be put in a separate box unless there is a restart. I would prefer to
not shift focus to Shell unless and until a module is run.
----------
priority: high -> normal
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue34857>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
