[issue47156] IDLE: make use of extended SyntaxError info.
Andre Roberge added the comment: > (Anyone really want log of error?) If by this you mean having access to the error from a known place (like sys.last_traceback or something else specific to IDLE but available from a script), then the answer from me is definitely yes. -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue47156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46902] Typo hint message for from-imports?
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue46902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46838] Parameters and arguments parser syntax error improvments
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue46838> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46652] Use code.co_qualname to provide richer information
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue46652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46637] Incorrect error message: "missing 1 required positional argument"
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue46637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43476] Enabling access to showsyntaxerror for IDLE's shell
Andre Roberge added the comment: As far as I am concerned, this issue can be closed. I have found a workaround which allows me to reproduce and analyze the SyntaxError that are not captured by custom exception hook. -- ___ Python tracker <https://bugs.python.org/issue43476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46237] Incorrect line reported in syntax error
Andre Roberge added the comment: > This also affects 3.9 I imagine, no? Yes. And, from what I can tell, the same incorrect line is indicated at least all the way back to Python 3.6 (where it was "invalid token" instead of "invalid decimal literal). -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue46237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46291] [doc] First argument to raise can also be BaseException
Andre Roberge added the comment: >> For this advice (catching Exception and not BaseException) to be correct, >> users should be advised (as they are in the tutorial) to raise exceptions >> derived from Exception (and not BaseException). > I disagree with that. You are a core developer and I just an end-user. I respect your expertise and will no longer comment. -- ___ Python tracker <https://bugs.python.org/issue46291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46291] [doc] First argument to raise can also be BaseException
Andre Roberge added the comment: Irit: In all the books and tutorials I have seen, the advice is to try to catch specific exceptions whenever possible or, *at most*, to catch Exception (and not BaseException). This is to allow, for example, a program to be interrupted by a KeyboardInterrupt. As you know, the hierarchy is as follows: BaseException +-- SystemExit +-- KeyboardInterrupt +-- GeneratorExit +-- Exception +-- all others If specific action to do some cleanup before a SystemExit (usually the result of calling sys.exit()) or catching some KeyboardInterrupt (which is generally NOT done via a raise statement), then these specific exception should be caught. The documentation refers to GeneratorExit as not indicating an error needing to be caught by users. For this advice (catching Exception and not BaseException) to be correct, users should be advised (as they are in the tutorial) to raise exceptions derived from Exception (and not BaseException). -- ___ Python tracker <https://bugs.python.org/issue46291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46291] [doc] First argument to raise can also be BaseException
Andre Roberge added the comment: Irit: Gregor indicates that, while the tutorial refers to "a class that derives from Exception", the Python Reference Language states exceptions should be subclasses of BaseException (which Exception *is*). You then invited Gregor to submit a patch to change the wording of the tutorial (implying that it would refer to a class that derives from BaseException). I pointed out that the advice given elsewhere is that user-defined exceptions should derive from Exception (thus, not from BaseException), so that nothing should be changed in the tutorial, and no change should be submitted. So, as I understand it: there is a strict hierarchy of exceptions classes, all inheriting from BaseException. However, user-defined exceptions should be derived from Exception (and not BaseException), as indicated in the tutorial and on the page describing what each exception indicates. If that is correct, nothing needs to be changed in the tutorial. -- ___ Python tracker <https://bugs.python.org/issue46291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46291] [doc] First argument to raise can also be BaseException
Andre Roberge added the comment: In https://docs.python.org/3/library/exceptions.html#Exception, it is written: "All built-in, non-system-exiting exceptions are derived from this class. All user-defined exceptions should also be derived from this class." Yes, technically, the root of all exceptions is BaseException. However, this seems to indicate that the advice given in the tutorial is correct. -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue46291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46240] Incorrect hint about forgetting a comma
New submission from Andre Roberge : Given the following code containing an unclosed parenthesis: a = (1, 2 b = 3 Here is the resulting SyntaxError: > python ignore.py File "C:\...\ignore.py", line 1 a = (1, 2 ^ SyntaxError: invalid syntax. Perhaps you forgot a comma? This incorrect hint is present in 3.10.1 and 3.11.0a3. -- components: Parser messages: 409578 nosy: aroberge, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: Incorrect hint about forgetting a comma versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44780] Incorrect message: "Invalid decimal literal" (python 3.10)
Andre Roberge added the comment: The last of these three cases (with FRACTION SLASH) is fixed 3.10.1. The other two are still present in 3.10.1 and in 3.11.0a3 -- versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue44780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46042] Error range of "duplicate argument" SyntaxErrors is too big
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue46042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46004] Incorrect bad token identified in 3.10.1
Andre Roberge added the comment: >From >(https://friendly-traceback.github.io/docs/syntax_tracebacks_en_3.10.html#for-loop-missing-in-operator), > this is what was shown for Python 3.10.0 for x range(4): ^^ SyntaxError: invalid syntax. Perhaps you forgot a comma? Same as Python 3.11.0a2. -- ___ Python tracker <https://bugs.python.org/issue46004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46004] Incorrect bad token identified in 3.10.1
New submission from Andre Roberge : In Python 3.10.1, a change occurred compared with 3.10.0 so that an incorrect token is flagged for a SyntaxError. Also, in 3.11.0a2, the suggestion made about having forgotten a comma is incorrect. Python 3.10.1 for x range(4): ^ SyntaxError: invalid syntax (I no longer have 3.10.0 available but I know from my tests that it was identifying correctly the wrong token.) Python 3.11.0a2 for x range(4): ^^ SyntaxError: invalid syntax. Perhaps you forgot a comma? Python 3.9.5 for x range(4): ^ SyntaxError: invalid syntax Python 3.8.10 for x range(4): ^ SyntaxError: invalid syntax Python 3.7.8 for x range(4): ^ SyntaxError: invalid syntax Python 3.6.8 for x range(4): ^ SyntaxError: invalid syntax -- components: Parser messages: 407894 nosy: aroberge, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: Incorrect bad token identified in 3.10.1 versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44166] Make IndexError messages for list more informative
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue44166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45812] SystemError when using code.interact
Andre Roberge added the comment: I am sorry, but I am not set up to work from the main branch and must rely on official releases. In the future, for alpha and beta releases, I will try to wait for the next release, see immediately if I can reproduce bugs that I had noted before, and submit then at that time. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45812] SystemError when using code.interact
New submission from Andre Roberge : In the following, I execute a single invalid statement in the Python interpreter, which gives the correct error message. Afterwards, I repeat this example using code.interact(), generating a different traceback. This issue affects IDLE differently as shown in the attached file: the statement is never considered to be complete. === Python 3.11.0a2 (tags/v3.11.0a2:e2b4e4b, Nov 5 2021, 20:00:05) [MSC v.1929 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> a = 3 \ 4 File "", line 1 a = 3 \ 4 ^ SyntaxError: unexpected character after line continuation character >>> import code >>> code.interact() Python 3.11.0a2 (tags/v3.11.0a2:e2b4e4b, Nov 5 2021, 20:00:05) [MSC v.1929 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> a = 3 \ 4 ... Traceback (most recent call last): File "", line 1, in File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\code.py", line 301, in interact console.interact(banner, exitmsg) ^ File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\code.py", line 232, in interact more = self.push(line) ^^^ File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\code.py", line 258, in push more = self.runsource(source, self.filename) ^ File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\code.py", line 63, in runsource code = self.compile(source, filename, symbol) ^^ File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\codeop.py", line 185, in __call__ return _maybe_compile(self.compiler, source, filename, symbol) ^^^ File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\codeop.py", line 96, in _maybe_compile code2 = compiler(source + "\n\n", filename, symbol) ^^^ File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\codeop.py", line 150, in __call__ codeob = compile(source, filename, symbol, self.flags, True) ^^^ SystemError: Negative size passed to PyUnicode_New -- components: Parser files: idle_problem.png messages: 406381 nosy: aroberge, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: SystemError when using code.interact versions: Python 3.11 Added file: https://bugs.python.org/file50441/idle_problem.png ___ Python tracker <https://bugs.python.org/issue45812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45811] Improve error message when source code contains invisible control characters
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue45811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45807] Strange SyntaxError message / suggestions for "@x = 123"
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue45807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45801] Incorrect "Perhaps you forgot a comma" hint
Andre Roberge added the comment: I understand. I reported this issue when one of my newest tests failed with Python 3.10 and 3.11. Actually, using friendly-traceback, using the location of the exception as indicated by cPython 3.10 and 3.11, here's part of the explanation it gives: The following lines of code would not cause any `SyntaxError`: sum + [i for i in [1, 2, 3] if i%2==0] sum - [i for i in [1, 2, 3] if i%2==0] sum * [i for i in [1, 2, 3] if i%2==0] sum, [i for i in [1, 2, 3] if i%2==0] Note: these are just some of the possible choices and that some of them might raise other types of exceptions. So, I agree with you that suggesting a comma would be appropriate. (I also miss the suggestion of inserting an equal sign above). Meanwhile, with prior versions of cPython, here's the suggestion that was offered: You used square brackets, `[...]` instead of parentheses. Write the following instead: sum(i for i in [1, 2, 3] if i%2==0) So, since using the suggestion currently by cPython (3.10, 3.11), one could get a syntactically valid statement by adding a comma, I cannot really argue that this is a bug. (Sorry, I should have checked in more details before.) Therefore, I agree that this issue should probably be closed ... unless you find that suggesting a missing comma while there are many other possible operators that could be inserted could be considered as misleading. -- ___ Python tracker <https://bugs.python.org/issue45801> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45801] Incorrect "Perhaps you forgot a comma" hint
New submission from Andre Roberge : Python 3.10 and 3.11: >>> sum[i for i in [1, 2, 3] if i%2==0] File "", line 1 sum[i for i in [1, 2, 3] if i%2==0] ^^^ SyntaxError: invalid syntax. Perhaps you forgot a comma? Furthermore, I don't find that highlighting the entire statement (or parts of it, if we use print(sum[...]) is very useful in attempting to find the source of the error. In previous versions, we would get the following: >>> sum[i for i in [1, 2, 3] if i%2==0] File "", line 1 sum[i for i in [1, 2, 3] if i%2==0] ^ SyntaxError: invalid syntax -- components: Parser messages: 406287 nosy: aroberge, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: Incorrect "Perhaps you forgot a comma" hint versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue45801> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45781] Deleting __debug__ should be an SyntaxError
Andre Roberge added the comment: What version are you using? As far as I can test, it has become a syntax error since 3.10. Here is the result with the latest 3.11 alpha > python Python 3.11.0a2 (tags/v3.11.0a2:e2b4e4b, Nov 5 2021, 20:00:05) [MSC v.1929 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> del __debug__ File "", line 1 SyntaxError: cannot delete __debug__ >>> exit() > python Python 3.11.0a2 (tags/v3.11.0a2:e2b4e4b, Nov 5 2021, 20:00:05) [MSC v.1929 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def f(): ...del __debug__ ... File "", line 2 SyntaxError: cannot delete __debug__ -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue45781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45738] 3.11 exec raises SystemError instead of SyntaxError on char after line continuation
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue45738> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45759] Improve error messages for non-matching `elif`/`else` statements
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue45759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45721] Improve error message when python shell command is entered at the REPL prompt
Andre Roberge added the comment: I think that "trying to run a shell command" might not be easy to understand by a beginner. If the special case of r"python\s+" is added, perhaps r"pip\s+" should be considered as well since many sites on the Internet suggest to install packages using "pip install ..." instead of "python -m pip install ..." -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue45721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45716] Confusing parsing error message when trying to use True as keyword argument
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue45716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45607] Make it possible to enrich an exception's error message
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue45607> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45560] sys.last_* not set for SyntaxErrors with IDLE
Andre Roberge added the comment: If this can be implemented, then I believe that https://bugs.python.org/issue43476 could be closed as well. -- ___ Python tracker <https://bugs.python.org/issue45560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45560] sys.last_* not set for SyntaxErrors with IDLE
New submission from Andre Roberge : As stated in the documentation, sys.last_type, sys.last_value and sys.last_traceback ... are set when an exception is not handled and the interpreter prints an error message and a stack traceback. This is true whether the exception is a SyntaxError or some runtime error when a standard Python interpreter is used. However, when the IDLE shell is used and a SyntaxError occurs, these are not set. If it is not possible to change this behaviour in IDLE, perhaps the documentation of the sys module should be amended to include this information. -- assignee: terry.reedy components: IDLE messages: 404669 nosy: aroberge, terry.reedy priority: normal severity: normal status: open title: sys.last_* not set for SyntaxErrors with IDLE versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45450] Improve syntax error for parenthesized arguments
Andre Roberge added the comment:
+1 on adding better error messages for these cases. I also agree with having
different explanations with lambda and def.
Below is what I have with friendly-traceback: perhaps the first line of both of
these might be suitable? (I will likely change the first line in each case to
be as similar to what you end up with.)
>>> set_include("why")
>>> lambda (x, y): x + y
`lambda` does not allow parentheses around its arguments.
This was allowed in Python 2 but it not allowed in Python 3.
>>> def foo(x, (y, z), w):
You cannot have explicit tuples as function arguments.
You can only use identifiers (variable names) as function arguments.
Assign any tuple to a parameter and unpack it
within the body of the function.
--
___
Python tracker
<https://bugs.python.org/issue45450>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45450] Improve syntax error for parenthesized arguments
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue45450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24612] not operator expression raising a syntax error
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue24612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45000] del __debug__ should be a SyntaxError
New submission from Andre Roberge : Consider the following: Python 3.10.0rc1 ... >>> __debug__ True >>> del __debug__ Traceback (most recent call last): File "", line 1, in NameError: name '__debug__' is not defined >>> __debug__ True >>> __debug__ = False File "", line 1 SyntaxError: cannot assign to __debug__ I suggest that attempting to delete __debug__ should be a SyntaxError, similar to attempting to delete None and other constants. >>> del None File "", line 1 del None SyntaxError: cannot delete None = = = The same NameError exception is raised for Python 3.9 when attempting to delete __debug__. For Python 3.8, attempting to delete __debug__ silently fails, so the current behaviour is at least an improvement. -- components: Parser messages: 400256 nosy: aroberge, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: del __debug__ should be a SyntaxError type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45000> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44947] SyntaxError: trailing comma not allowed ... misleading
Andre Roberge added the comment: Based on what I just read on https://github.com/davidhalter/parso/blob/master/parso/python/issue_list.txt I gather that this exception is only raised in the context of an import statement with a trailing comma (usually followed by nothing). -- ___ Python tracker <https://bugs.python.org/issue44947> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44947] SyntaxError: trailing comma not allowed ... misleading
Andre Roberge added the comment: This message is not new to Python 3.10 as it is also shown with Python 3.9.5. >>> from math import sin, cos, and tan File "", line 1 from math import sin, cos, and tan ^ SyntaxError: trailing comma not allowed without surrounding parentheses -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue44947> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44947] SyntaxError: trailing comma not allowed ... misleading
New submission from Andre Roberge : Consider the following four slightly different examples: Python 3.10.0rc1 ... >>> from math import sin and cos File "", line 1 from math import sin and cos ^^^ SyntaxError: invalid syntax >>> from math import sin, cos, and tan File "", line 1 from math import sin, cos, and tan ^^^ SyntaxError: trailing comma not allowed without surrounding parentheses >>> from math import (sin, cos,) and tan File "", line 1 from math import (sin, cos,) and tan ^^^ SyntaxError: invalid syntax >>> from math import sin, cos and tan File "", line 1 from math import sin, cos and tan ^^^ SyntaxError: invalid syntax In all four cases, the keyword 'and' is correctly identified as causing the error. In the second case, the message given may suggest that adding parentheses is all that is needed to correct the problem; however, that is "obviously" not the case as shown in the third case. **Perhaps** when a _keyword_ like 'and' is identified as a problem, a generally better message would be something like SyntaxError: the keyword 'and' is not allowed here leaving out all guesses like 'surrounding by parentheses', "meaning == instead of =", 'perhaps forgot a comma', etc., which are sometimes added by Python 3.10+ ? I am fully and painfully aware that attempting to provide helpful and accurate error message is challenging... -- components: Parser messages: 399837 nosy: aroberge, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: SyntaxError: trailing comma not allowed ... misleading versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44947> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34013] Inconsistent SyntaxError for print
Andre Roberge added the comment: Python 3.10.0rc1 ... >>> print hello world! File "", line 1 print hello world! ^^^ SyntaxError: invalid syntax. Perhaps you forgot a comma? The hint given is not exactly helpful ... (This example was in a discussion on Twitter https://twitter.com/cfbolz/status/1425036431974715400 about a previous handling of this invalid syntax case where it was mentioned that pypy verifies that the suggestion it makes actually yields syntactically valid code.) -- ___ Python tracker <https://bugs.python.org/issue34013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44838] SyntaxError: New message "expected 'else' after 'if' expression" wrongly shown
Andre Roberge added the comment: I have no idea how the parser works ... but when you do the test to identify if an 'else' is missing, could the fact that there is a colon instead of the expected 'else' be used to avoid misidentifying this case? Note: I am keenly aware of the difficulties in identifying possible cause of syntax errors and do appreciate the many improvements that have been done. -- ___ Python tracker <https://bugs.python.org/issue44838> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44838] SyntaxError: New message "expected 'else' after 'if' expression" wrongly shown
New submission from Andre Roberge :
Given the following code containing no if expression (only if statements):
if True:
print('hello'
if 2:
print(123))
The following traceback is generated in Python 3.10.0RC1
File "...\example.py", line 2
print('hello'
^^^
SyntaxError: expected 'else' after 'if' expression
--
components: Parser
messages: 398989
nosy: aroberge, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: SyntaxError: New message "expected 'else' after 'if' expression" wrongly
shown
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44838>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44792] Improve syntax errors for invalid if expressions
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue44792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44780] Incorrect message: "Invalid decimal literal" (python 3.10)
Andre Roberge added the comment: Third case. Showing only the output for Python 3.10 >>> a = 3 ⁄ 7 # entered with a space around ⁄ File "", line 1 a = 3 ⁄ 7 ^ SyntaxError: invalid character '⁄' (U+2044) >>> a = 3⁄7# no added space File "", line 1 a = 3⁄7 ^ SyntaxError: invalid decimal literal = = In the terminal, the integers 3 and 7 look the same with or without spaces around the ⁄ character, known as FRACTION SLASH. -- ___ Python tracker <https://bugs.python.org/issue44780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44780] Incorrect message: "Invalid decimal literal" (python 3.10)
Andre Roberge added the comment: Here's another related case. Python 3.9: >>> a = 1½ File "", line 1 a = 1½ ^ SyntaxError: invalid character '½' (U+00BD) Python 3.10 >>> a = 1½ File "", line 1 a = 1½ ^ SyntaxError: invalid decimal literal -- ___ Python tracker <https://bugs.python.org/issue44780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44780] Incorrect message: "Invalid decimal literal" (python 3.10)
New submission from Andre Roberge : Consider the following: >>> a = (1‚ 2) # not a comma, but unicode character. Using Python 3.9 (and earlier), we get the following correct information >>> a = (1‚ 2) File "", line 1 a = (1‚ 2) ^ SyntaxError: invalid character '‚' (U+201A) Using Python 3.10, we get the following incorrect information instead: >>> a = (1‚ 2) File "", line 1 a = (1‚ 2) ^ SyntaxError: invalid decimal literal -- messages: 398556 nosy: aroberge, pablogsal priority: normal severity: normal status: open title: Incorrect message: "Invalid decimal literal" (python 3.10) versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44648] Inspect.getsource raises wrong error on classes in interactive session
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue44648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11343] Make errors due to full parser stack identifiable
Andre Roberge added the comment: @pablo: Sincere apologies ... I tested this with the wrong virtual environment active locally. With 3.10, it is indeed SyntaxError: too many nested parentheses -- ___ Python tracker <https://bugs.python.org/issue11343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11343] Make errors due to full parser stack identifiable
Andre Roberge added the comment: For information: I created an actual .py file from the last example with 200 parens and got the following error message: > python example.py s_push: parser stack overflow MemoryError For consistency and greater clarity, I think that having messages such as - SyntaxError: parser stack overflow (too many nested parenthesis) - SyntaxError: parser stack overflow (too many statistically nested blocks) and possibly others (too many arguments?), would be preferable, with the possibility of simply having - SyntaxError: parser stack overflow if the exact cause cannot be identified at the parsing stage. -- ___ Python tracker <https://bugs.python.org/issue11343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44576] AttributeError: incorrect line identified in Python 3.10
Andre Roberge added the comment: While I filed the original report, I am in agreement that accurate information for debugging tools is definitely more important than the quick summary shown in the traceback, and that the change likely represents an improvement in situations more realistic than the contrived example I gave. -- ___ Python tracker <https://bugs.python.org/issue44576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44576] AttributeError: incorrect line identified in Python 3.10
New submission from Andre Roberge : Consider the following program # example.py one = 1 two = "two" a = [one . two] Running this program with Python versions before 3.10, yields the following traceback: Traceback (most recent call last): File "C:\Users\andre\example.py", line 3, in a = [one AttributeError: 'int' object has no attribute 'two' The line shown correctly includes the 'int' object. I have verified that this is the case for Python 3.6 to 3.9 inclusively. However, with Python version 3.10.0b3, the following traceback is generated: Traceback (most recent call last): File "C:\Users\andre\example.py", line 5, in two] AttributeError: 'int' object has no attribute 'two' -- messages: 397067 nosy: aroberge priority: normal severity: normal status: open title: AttributeError: incorrect line identified in Python 3.10 versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43950] Include column offsets for bytecode instructions
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue43950> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43476] Enabling access to showsyntaxerror for IDLE's shell
Andre Roberge added the comment: I made an error in my previous comment: the code I wrote is obviously incorrect as it contains a SyntaxError. -- ___ Python tracker <https://bugs.python.org/issue43476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43476] Enabling access to showsyntaxerror for IDLE's shell
Andre Roberge added the comment: I can confirm that, if the existing line type, value, tb = sys.exc_info() in pyshell.ModifiedInterpreter.showsyntaxerror is replaced by e_type, value, tb = sys.exc_info() err = str((type(e_type).__name__, *value)+'\n' linecache.cache[""] = (len(err), 0, [err], "") then all the required information to analyze the cause of the error can be retrieved using rpc. Aside: In doing various tests, I noticed that "IndentationError" are simply reported as "SyntaxError" in Idle, since at least Python 3.6. This is just a cosmetic issue. -- ___ Python tracker <https://bugs.python.org/issue43476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43476] Enabling access to showsyntaxerror for IDLE's shell
Andre Roberge added the comment: Unless I am mistaken, when compiling the code, both SyntaxError and OverflowError instances are caught at the same stage, and likely passed on to showsyntaxerror. For OverflowError, e.args is not normally a tuple but a string, and *e.args[1] would raise an exception. -- ___ Python tracker <https://bugs.python.org/issue43476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43476] Enabling access to showsyntaxerror for IDLE's shell
Andre Roberge added the comment: Having a fake file with a single line containing all the exception information as described would definitely provide all the required information needed. It would be much better than what I had suggested previously. -- ___ Python tracker <https://bugs.python.org/issue43476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43476] Enabling access to showsyntaxerror for IDLE's shell
Andre Roberge added the comment: I just thought of making a copy of the file content under a known name as the least disruptive approach for IDLE's code - even less so than the recent addition required to support user-defined exception hooks. For SyntaxErrors and subclasses [1], Friendly needs the source code as well as the error message, offset, lineno (end_offset and end_lineno if they are present) in order to perform its analysis. In all cases (i.e not only with IDLE but with other environments like Jupyter notebooks), it retrieves this source code from the given filename using the linecache module. If it were possible to get those exception arguments using RPC, this would be much better than what I suggested. This might also be much more useful that what I suggest for any third-party code wanting access to the traceback information for SyntaxErrors. However, I could not find a simple way of doing this. [1] The required information for run-time errors, such as NameError, etc., is already available with sys.excepthook. -- ___ Python tracker <https://bugs.python.org/issue43476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43476] Enabling access to showsyntaxerror for IDLE's shell
Andre Roberge added the comment: Would it be possible to add a single line of code to idlelib's pyshell.py, as indicated below: def showsyntaxerror(self, filename=None): """... """ linecache.cache[""] = linecache.cache[filename] # here tkconsole = self.tkconsole ... Of course, another name than "" could be chosen. This would allow users (like me, with Friendly) to retrieve the code that caused a SyntaxError and process it as they wish. In my case, it would allow me to reproduce the SyntaxError and have Friendly provide an explanation and possible suggestions for fixing the error. This would complement the new support for user defined sys.excepthook introduced in Python 3.10. -- ___ Python tracker <https://bugs.python.org/issue43476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44448] Suggestion: change existing error message for invalid function name
New submission from Andre Roberge : Consider the following two examples with the latest beta release: Python 3.10.0b3 ... >>> def 3job(x): File "", line 1 def 3job(x): ^ SyntaxError: invalid imaginary literal >>> def 3ob(x): File "", line 1 def 3ob(x): ^ SyntaxError: invalid decimal literal In most situations, these error messages are fantastic improvements compared with what was done previously. Here however, as they are intended to be used as function names, perhaps they could be improved. **If** it is easy to check if those "invalid number literals" are preceded by "def" during the analysis, perhaps a better error message might be SyntaxError: invalid function name If such an analysis would be difficult to do, I would suggest to simply close this issue as these examples are probably almost never going to be seen in real-life situations. (One might also consider to change the error message in the cases of "invalid octal" and "invalid hexadecimal" when they are used as function names.) -- components: Parser messages: 396027 nosy: aroberge, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: Suggestion: change existing error message for invalid function name versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue8> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44447] Syntax Error not as detailed as shown
Andre Roberge added the comment: Your example is different than the one in the documentation (What's new). >>> (x, x for x in range(7)) # Your example File "", line 1 (x, x for x in range(7)) ^^^ SyntaxError: invalid syntax >>> foo(x, x for x in range(7)) # Example similar to the docs File "", line 1 foo(x, x for x in range(7)) ^^^ SyntaxError: Generator expression must be parenthesized >>> [x, x for x in range(7)] # Yet a different example File "", line 1 [x, x for x in range(7)] SyntaxError: did you forget parentheses around the comprehension target? -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue7> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44324] add a "expected expression" syntax error
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue44324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44369] Improve syntax error for wrongly closed strings
Andre Roberge added the comment: I like this. While it would be a bit longer, I'm wondering if the message should not read instead as follows: ... Did you use the same quotes here as those enclosing the string? === I suspect that errors coming from the use of a single quote, as in: 'Don't do this' might be just as prevalent if not more so; however, they might be more difficult to properly diagnose. -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue44369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44335] "Wrong" invalid character identified
New submission from Andre Roberge : When using Python 3.10.0b2 on a line with more than one invalid characters, the second one is identified as being incorrect, whereas in previous versions the first such character was identified. > py -3.8 unicode_quote.py File "unicode_quote.py", line 2 a = « hello » « world » ^ SyntaxError: invalid character in identifier > py -3.9 unicode_quote.py File "C:\...\unicode_quote.py", line 2 a = « hello » « world » ^ SyntaxError: invalid character '«' (U+00AB) > py -3.10 unicode_quote.py File "C:\...\unicode_quote.py", line 2 a = « hello » « world » ^ SyntaxError: invalid character '»' (U+00BB) -- messages: 395267 nosy: aroberge, pablogsal priority: normal severity: normal status: open title: "Wrong" invalid character identified versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44335> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?
Andre Roberge added the comment: Terry: I just checked with Idle on Windows with Python 3.9.5 and the display works perfectly, with no incorrect characters. -- ___ Python tracker <https://bugs.python.org/issue44275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37041] IDLE: path browser unusable on some displays
Change by Andre Roberge : -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue37041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44273] Assigning to Ellipsis should be the same as assigning to __debug__
Andre Roberge added the comment: Up to your best judgment Pablo - and thanks for your ongoing work on improving error messages. -- ___ Python tracker <https://bugs.python.org/issue44273> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44273] Assigning to Ellipsis should be the same as assigning to __debug__
Andre Roberge added the comment:
>
> I think that the suggestion to explicitly refer to '...' instead of the
name Ellipsis would be preferable.
Aside: I had not realized that this was done at a different stage for
__debug__ and Ellipsis ("Ignorance is bliss"...) and do realize that this
is a rare corner case that a beginner would almost never encountered.
(I'm just trying my best to prevent any kind of confusion in my own
program, and probably overestimate the potential for confusion here for
cPython users).
--
___
Python tracker
<https://bugs.python.org/issue44273>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?
Andre Roberge added the comment: I observe something similar, though with different symbols. My Windows installation uses French (fr-ca) as default language. === help> COMPARISON Comparisons *** ... Formally, if *a*, *b*, *c*, à, *y*, *z* are expressions and *op1*, *op2*, à, *opN* are comparison operators, then "a op1 b op2 c ... y opN z" is equivalent to "a op1 b and b op2 c and ... y opN z", except that each expression is evaluated at most once. Note that "a op1 b op2 c" doesnÆt imply any kind of comparison between *a* and *c*, so that, e.g., "x < y > z" is perfectly legal (though perhaps not pretty). So, in my case, the unusual characters are: à, Æ. In this case, the French word 'à' would make some sense in this context (as it means 'to' in English). -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue44275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44273] Assigning to Ellipsis should be the same as assigning to __debug__
New submission from Andre Roberge : Consider the following in Python 3.10 >>> ... = 1 File "", line 1 ... = 1 ^^^ SyntaxError: cannot assign to Ellipsis here. Maybe you meant '==' instead of '='? >>> __debug__ = 1 File "", line 1 SyntaxError: cannot assign to __debug__ In prior Python versions, assignments to Ellisis written as ... were treated the same as assignment to __debug__. I believe that the old message was a better choice. The error message about assigning to Ellipsis (...) is made even more confusing since Ellipsis (the name) can be assigned to a different value. >>> ... == Ellipsis True >>> Ellipsis = 1 >>> ... == Ellipsis False >>> ... Ellipsis -- components: Interpreter Core messages: 394808 nosy: aroberge priority: normal severity: normal status: open title: Assigning to Ellipsis should be the same as assigning to __debug__ versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44273> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44201] REPL requests another line despite syntax error
Andre Roberge added the comment: I believe that this is similar to, but not quite as severe as a similar bug in code.interact() https://bugs.python.org/issue43366 which affects IDLE; perhaps fixing this might fix the other issue? -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue44201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44181] SyntaxError in Python 3.10.0b1: wrong token for missing comma
New submission from Andre Roberge :
When forgetting a comma in writing a dict literal spanning multiple lines,
the "bad token" is wrongly idenfied with Python 3.10.0b1.
>>> a = {'a': 1
... 'b': 2
File "", line 1
a = {'a': 1
^
SyntaxError: invalid syntax. Perhaps you forgot a comma?
Previously, this was shown:
>>> a = {'a': 1
... 'b': 2
File "", line 2
'b': 2
^
SyntaxError: invalid syntax
However, I hasten to add that the new hint about a missing comma is spot on,
and likely to be extremely useful.
Note: this is based on my "intuition" built from previous version where the
token identified by ^
was the first token that the Python parser was not able to make sense of.
Now that the parser highlight a range (if relevant tokens are on a single line),
it makes sense to include tokens preceding the "bad token".
However, when we have an error where such range
spans multiple lines, it can create "problems" such as that shown above.
Perhaps this is not worth attempting to fix and Python programmers like me will
have to develop a "new intuition" in such cases (and "fix" friendly so that it
can figure out the correct "bad token"
independently of cPython's information)
... and this bug report can be simply closed.
--
components: Parser
messages: 393976
nosy: aroberge, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: SyntaxError in Python 3.10.0b1: wrong token for missing comma
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44181>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44180] SyntaxError misidentified in 3.10.0b1 when = used instead of : in dict literal
Andre Roberge added the comment:
In the second case, I understand very well that it could have been a set
literal. In my (limited) experience, I have never seen a set literal containing
a single element obtained from an == comparison.
Since dict can be built by using keyword arguments, I tend to assume that using
= in an literal that starts with { is meant to be a dict.
In
>>> ages = {'Alice' = 22}
replacing the equal sign by either ==, :, or a comma would generate no
SyntaxError. Clearly (in my mind anyway, and in previous Python versions), the
"bad token" is the equal sign, and not the string Alice.
Here's what I show with friendly:
==
>>> ages = {'Alice'=22}
Traceback (most recent call last):
File "", line 1
ages = {'Alice'=22}
^
SyntaxError: invalid syntax
>>> why()
It is possible that you used an equal sign = instead of a colon : to assign
values to keys in a dict before or at the
position indicated by ^.
=
Admitedly, this suggestion could also be wrong - but the focus on this case
(imo) should be on the "bad token" shown, which should be the equal sign.
--
___
Python tracker
<https://bugs.python.org/issue44180>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44180] SyntaxError misidentified in 3.10.0b1 when = used instead of : in dict literal
New submission from Andre Roberge :
When an equal sign is used instead of a colon in creating a dict literal,
depending on the context, either the "bad token" is misidentified OR the
would-be helpful error message is incorrect in this particular case.
1) Example of bad token.
Previously, the = sign was identified correctly:
>>> ages = {'Alice'=22, 'Bob'=23}
File "", line 1
ages = {'Alice'=22, 'Bob'=23}
^
SyntaxError: invalid syntax
With Python 3.10.0b1, the comma is identified as the bad token:
>>> ages = {'Alice'=22, 'Bob'=23}
File "", line 1
ages = {'Alice'=22, 'Bob'=23}
^
SyntaxError: invalid syntax
2) Example of incorrect error message
Previously, we got the traditional and unhelpful "invalid syntax" but with the
bad token identified correctly:
>>> ages = {'Alice'=22}
File "", line 1
ages = {'Alice'=22}
^
SyntaxError: invalid syntax
With Python 3.10.0b1, we get the following:
>>> ages = {'Alice'=22}
File "", line 1
ages = {'Alice'=22}
^^^
SyntaxError: cannot assign to literal here. Maybe you meant '==' instead of '='?
I suspect that the ratio (== suggestion correct/ : suggestion correct) would be
vanishingly small. ;-)
--
components: Parser
messages: 393964
nosy: aroberge, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: SyntaxError misidentified in 3.10.0b1 when = used instead of : in dict
literal
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44180>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44026] IDLE: print "Did you mean?" for AttributeError and NameError
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue44026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43914] Highlight invalid ranges in SyntaxErrors
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue43914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43859] Improve syntax error for indentation errors
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue43859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38530] Offer suggestions on AttributeError and NameError
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue38530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43797] Improve syntax error for invalid comparisons
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue43797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43748] Inconsistent grammar in new error message (introduced in 3.10.0a7)
Andre Roberge added the comment: Since all the messages I track so far (https://github.com/aroberge/friendly/blob/master/friendly/syntax_errors/message_analyzer.py) had been changed when going from 6.7 to 3.8, I had (incorrectly) assumed that all such error messages been changed to use cannot instead of can't. However, based on Serhyi's search, I gather that this is not the case and this specific issue can probably be closed as being irrelevant. -- ___ Python tracker <https://bugs.python.org/issue43748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43748] Inconsistent grammar in new error message (introduced in 3.10.0a7)
New submission from Andre Roberge :
Python version 3.10.0a7 added a more informative error message for:
>>> f"{**k}"
File "", line 1
(**k)
^
SyntaxError: f-string: can't use double starred expression here
Previously, the message was simply "SyntaxError: invalid syntax". So, this
change is certainly a welcome addition.
However, as far as I can tell, starting with Python 3.8, all previous uses of
"can't" in error messages were replaced by "cannot". Although it is an
extremely minor point, it might be preferable for consistency to replace
"can't" by "cannot" in this new error message.
--
components: Interpreter Core
messages: 390323
nosy: aroberge
priority: normal
severity: normal
status: open
title: Inconsistent grammar in new error message (introduced in 3.10.0a7)
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue43748>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43555] Location of SyntaxError with new parser missing (after continuation character)
New submission from Andre Roberge : Normally, for SyntaxErrors, the location of the error is indicated by a ^. There is at least one case where the location is missing for 3.9 and 3.10.0a6 where it was shown before. Using the old parser for 3.9, or with previous versions of Python, the location is shown. Python 3.10.0a6 ... on win32 >>> a = 3 \ 4 File "", line 1 SyntaxError: unexpected character after line continuation character >>> Python 3.9.0 ... on win32 Type "help", "copyright", "credits" or "license" for more information. >>> a = 3 \ 4 File "", line 1 SyntaxError: unexpected character after line continuation character >>> Using the old parser with Python 3.9, the location of the error is shown *after* the unexpected character. > python -X oldparser Python 3.9.0 ... on win32 >>> a = 3 \ 4 File "", line 1 a = 3 \ 4 ^ SyntaxError: unexpected character after line continuation character >>> Using Python 3.8 (and 3.7, 3.6), the location is pointing at the unexpected character. Python 3.8.4 ... on win32 >>> a = 3 \ 4 File "", line 1 a = 3 \ 4 ^ SyntaxError: unexpected character after line continuation character >>> -- components: Interpreter Core messages: 389071 nosy: aroberge priority: normal severity: normal status: open title: Location of SyntaxError with new parser missing (after continuation character) type: behavior versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43476] Enabling access to showsyntaxerror for IDLE's shell
New submission from Andre Roberge : As a result of https://bugs.python.org/issue43008, IDLE now supports custom exception hook for almost all cases except for code entered in the interactive shell that result in SyntaxError. It would be useful for some applications if a way to replace the error handling currently done by IDLE for this particular case was made available to user code. I consider this to be in the "would be nice to have" category, but in no means a high priority item. -- assignee: terry.reedy components: IDLE messages: 388524 nosy: aroberge, terry.reedy priority: normal severity: normal status: open title: Enabling access to showsyntaxerror for IDLE's shell type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43366] Unclosed bracket bug in code.interact prevents identifying syntax errors
Andre Roberge added the comment: I understand the challenge of reproducing the behaviour of the Python interpreter for this case. If it cannot be reproduced, then the documentation for https://docs.python.org/3/library/code.html#code.InteractiveConsole.interact and others on that page should probably be modified as it states that it "Closely emulate the interactive Python console." -- ___ Python tracker <https://bugs.python.org/issue43366> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43304] THONNY 3.3.0 failing to install package MULTIPROCESSING
Andre Roberge added the comment: Thonny has its own discussion site where you can report such problems: https://groups.google.com/g/thonny -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue43304> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34013] Inconsistent SyntaxError for print
Andre Roberge added the comment: +1 to the idea of adding something to the grammar, and have a simple error message: SyntaxError: Missing parentheses in call to 'print'. in *all* cases, including the first one that prompted this bug report. I write that even though I have created a third-party package based on the idea that beginners (and sometimes others...) might benefit from a more detailed error message (which is taken care of already by friendly-traceback). -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue34013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18163] Add a 'key' attribute to KeyError
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue18163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43163] code.interact() unexpectedly raises exception when there may be more code
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue43163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43149] Misleading error message for except with missing parens (3.10.a5)
New submission from Andre Roberge : The following: try: pass except ValueError, NameError as err: pass results in: except ValueError, NameError as err: ^ SyntaxError: expected ':' However, what is missing here are some parentheses surrounding the exception types. -- messages: 386570 nosy: aroberge priority: normal severity: normal status: open title: Misleading error message for except with missing parens (3.10.a5) type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43008] IDLE ignores sys.excepthook in normal, subprocess mode
Andre Roberge added the comment: Terry: as per your earlier comment, I have tried to use Friendly-traceback with the latest version. While it does set the exception hook correctly, it is not useful. Friendly-traceback (FT) needs to have access to the code that was executed. FT's REPL caches the code (similarly to what IPython does, but not CPython) prior to execution so that it can retrieve it correctly, have access to the relevant execution frame, etc. This is not possible when using IDLE's REPL. In fact, for some types of exceptions, when FT tries to get access to the code, it ends up triggering secondary exceptions. However, using the method describe in FT's documentation (with relies on FT's own console) still works correctly. -- ___ Python tracker <https://bugs.python.org/issue43008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43121] Incorrect SyntaxError message for missing comma (3.10.a5)
Andre Roberge added the comment: Pablo: The tests are in https://github.com/aroberge/friendly-traceback/tree/master/tests/syntax I plan to soon add at least two dozen more based on recent contributions. The full results can be seen on the documentation site; for example https://aroberge.github.io/friendly-traceback-docs/docs/html/syntax_tracebacks_en_3.9.html I track changes in error messages from CPython: https://aroberge.github.io/friendly-traceback-docs/docs/html/compare.html -- ___ Python tracker <https://bugs.python.org/issue43121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43121] Incorrect SyntaxError message for missing comma (3.10.a5)
Andre Roberge added the comment:
Pablo: to run the friendly-traceback test suite is simply a matter of typing
"pytest" from the root directory of the repository (after installing the
dependencies). However, it would not be helpful for the purpose of CPython
development, as likely more failing tests would be due to Friendly-traceback
itself.
As a first step, Friendly-traceback tries to make use of the information given
by Python (for example, the new "expected ':'"); if it does not recognize the
message, or if the message is "invalid syntax", it uses some heuristics to
guess what might be the probable cause.
Improvements to the messages given by CPython are likely going to initially
result in failed tests for Friendly-traceback, whether the information provided
by CPython is valid (most of the time) or not.
The test suite I use includes things that I imagine a beginner might write. For
example, using "else if" instead of "elif". With one of the newest additions
of CPython ("expected ':'") which is accurate in most cases, this specific unit
test would likely fail until I make the appropriate adjustement to
Friendly-traceback.
--
___
Python tracker
<https://bugs.python.org/issue43121>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43121] Incorrect SyntaxError message for missing comma (3.10.a5)
Andre Roberge added the comment: Pablo: I have almost exactly the same 4 test cases that you added in the test suite, so it would pass my tests too. I would consider it to be resolved. (For example: https://aroberge.github.io/friendly-traceback-docs/docs/html/syntax_tracebacks_en_3.9.html#missing-comma-in-a-set -- although I need to fix the suggestions I offer in my own code as they are currently wrong.) -- ___ Python tracker <https://bugs.python.org/issue43121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43121] Incorrect SyntaxError message for missing comma (3.10.a5)
New submission from Andre Roberge : A missing comma between list items results in an incorrect message. Python 3.10.0a5 (tags/v3.10.0a5:b0478d7, Feb 3 2021, 01:44:54) [MSC v.1928 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> a = [1, 2 3] File "", line 1 a = [1, 2 3] ^ SyntaxError: did you forget parentheses around the comprehension target? -- messages: 386457 nosy: aroberge priority: normal severity: normal status: open title: Incorrect SyntaxError message for missing comma (3.10.a5) type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43117] Translation Mistakes
Andre Roberge added the comment: A similar error exists in the table for the French documentation where "valeurs" is indicated to be one of the options https://docs.python.org/fr/3.8/library/tkinter.ttk.html#widget -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue43117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43017] Improve error message in the parser when using un-parenthesised tuples in comprehensions
Andre Roberge added the comment: Such a change would be very useful and appreciated by other users as reported on https://github.com/aroberge/friendly-traceback/issues/167 and asked about on StackOverflow https://stackoverflow.com/questions/60986850/why-does-creating-a-list-of-tuples-using-list-comprehension-requires-parentheses -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue43017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36086] Split IDLE into separate feature in Windows installer
Andre Roberge added the comment: I do not use IDLE (except for testing) and would not be affected by such a change. However, many tutorials and books intended for beginners instruct users to use IDLE, with the assumption that it is available out of the box. Removing IDLE would immediately make instructions from those tutorials and books obsolete and needlessly confuse beginners who often struggle installing anything additional to a basic Python installation. I just checked and if I right-click on a Python file, I see 29 entries in the contextual menu, 28 of which would be unaffected if IDLE would be removed. If IDLE were not included by default (or if it required clicking on a checkbox), I think that the number of questions in various beginners forum about installing IDLE would quickly become a real annoyance for people that strive to help beginners. -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue36086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43008] IDLE ignores sys.excepthook in normal, subprocess mode
Andre Roberge added the comment: Terry: I will put it on my todo list. Friendly-traceback can currently work (indirectly) with IDLE; see https://aroberge.github.io/friendly-traceback-docs/docs/html/editor.html I am not sure what benefit this patch will yield when it comes to using Friendly-traceback with IDLE compared with what is currently possible. -- ___ Python tracker <https://bugs.python.org/issue43008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42955] Add sys.module_names: list of stdlib module names (Python and extension modules)
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue42955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42997] Improve error message for missing : before suites
Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue42997> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42577] Unhelpful syntax error when expression spans multiple lines
Andre Roberge added the comment: I suspect that the Python parser cannot easily be changed to given any other message. Replace the colon by "else" and add one more closing parenthesis and you have a valid Python program. So, is it a matter of an unclosed parenthesis, or not using "else" ? If you want possible additional help in such situations, you can try to use the third-party package friendly-traceback which gives the following information for this case (I put your code in a file named "ignore.py") Traceback (most recent call last): File "ignore.py", line 5 if 2: ^ SyntaxError: invalid syntax A `SyntaxError` occurs when Python cannot understand your code. Python could not understand the code in the file 'ignore.py' beyond the location indicated by --> and ^. 2: if 1: 3: print(((123)) 4: -->5: if 2: ^ 6: print(123) I make an effort below to guess what caused the problem but I might guess incorrectly. The opening parenthesis `(` on line 3 is not closed. 3: print(((123)) ^ -- nosy: +aroberge ___ Python tracker <https://bugs.python.org/issue42577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41488] Unusable type hint should not be silently ignored
New submission from Andre Roberge :
The following code is currently consistent with the type hint syntax but
contains a line that is completely ignored.
>>> d = {}
>>> d['a']: int
>>> d
{}
>>> __annotations__
{}
>>> '__annotations__' in dir(d)
False
I believe that type hints that cannot be either attached to an object nor added
to any other __annotations__ dict should either generate a SyntaxError or, at
the very least, result in a warning.
--
messages: 374884
nosy: aroberge
priority: normal
severity: normal
status: open
title: Unusable type hint should not be silently ignored
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue41488>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
