Pablo Galindo Salgado added the comment:
Regarding what to do, what I would love to optimize is that the message is
clear. One of the challenges people may have with too specific messages is that
they may not know what "a compiler" or "a parser" means (the first may be
especially confusing
Pablo Galindo Salgado added the comment:
As a piece of extra information, this limit has been there for a while:
https://github.com/python/cpython/blob/91a8f8c16ca9a7e2466a8241d9b41769ef97d094/Parser/tokenizer.h#L14
the problem is that the old parser died before reaching it in many
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
Pablo Galindo Salgado added the comment:
> > python example.py
> s_push: parser stack overflow
> MemoryError
That error can only happen with the old parser, so you must be using Python3.8
or 3.9 with the old parser. Can you confirm?
--
___
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
Terry J. Reedy added the comment:
I retract my original comment as I now agree with SyntaxError + distinct
message.
Given Irit's report, I think the remaining question is whether
A. The implication that 'too many nested parentheses' is compiler specific is
strong enough, and any thing
Irit Katriel added the comment:
The patch relates to the old parser.
With the new parser the 100*(+100*) example works. If we go to 1000 instead of
100 we get "SyntaxError: too many nested parentheses".
>From the discussion it seems that the idea of a new exception type for
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11343
___
___
Oh, I thought we never rely on exception message for anything
important. However this seems to be an exception for that exception.
:-)
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou pit...@free.fr added the comment:
Oh, I thought we never rely on exception message for anything
important. However this seems to be an exception for that exception.
:-)
I think you're missing the point. People usually don't catch SyntaxError
and run fallback code in this case.
Nick Coghlan ncogh...@gmail.com added the comment:
Yeah, at the level of *code* the origin doesn't really matter, so re-using the
exception type is actually OK. However, for *people* seeing the stack trace, it
may be useful to know what's genuinely illegal syntax and what's a limitation
of
Nick Coghlan ncogh...@gmail.com added the comment:
After further reflection, I (eventually) came to the same conclusion as
Benjamin and Antoine - using SyntaxError for this is fine.
However, the exception *message* should make it clear that this is an
implementation limit rather than a
Nick Coghlan ncogh...@gmail.com added the comment:
+1 for a new exception type to indicate this may technically be legal Python,
but this Python implementation cannot handle it correctly
Whatever exception type we add, it would be nice to also be able to use it if
someone eventually fixes the
Georg Brandl ge...@python.org added the comment:
I like SyntaxLimitError much better than ParserError.
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11343
___
Benjamin Peterson benja...@python.org added the comment:
2011/7/16 Nick Coghlan rep...@bugs.python.org:
Nick Coghlan ncogh...@gmail.com added the comment:
+1 for a new exception type to indicate this may technically be legal
Python, but this Python implementation cannot handle it correctly
Nick Coghlan ncogh...@gmail.com added the comment:
It's important to remember that other implementations treat CPython as
the gold standard for compatibility purposes. If we declare
something to be an ordinary SyntaxError, then that carries strong
implications for what other implementations
Benjamin Peterson benja...@python.org added the comment:
2011/7/16 Nick Coghlan rep...@bugs.python.org:
Nick Coghlan ncogh...@gmail.com added the comment:
It's important to remember that other implementations treat CPython as
the gold standard for compatibility purposes. If we declare
Nick Coghlan ncogh...@gmail.com added the comment:
It also makes it clear to users whether they've just run up against a
limitation of the implementation they're using or whether what they've
written is genuinely illegal code. They are NOT the same thing.
Attempting to conflate them into one
Benjamin Peterson benja...@python.org added the comment:
2011/7/16 Nick Coghlan rep...@bugs.python.org:
Nick Coghlan ncogh...@gmail.com added the comment:
It also makes it clear to users whether they've just run up against a
limitation of the implementation they're using or whether what
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11343
___
Nick Coghlan ncogh...@gmail.com added the comment:
It matters, because Python users are programmers, and most
programmers want to know *why* they're being told something is wrong.
Raising MemoryError is technically incorrect at this point, but at
least gives the right flavour of the user not
Benjamin Peterson benja...@python.org added the comment:
2011/7/16 Nick Coghlan rep...@bugs.python.org:
Nick Coghlan ncogh...@gmail.com added the comment:
It matters, because Python users are programmers, and most
programmers want to know *why* they're being told something is wrong.
Antoine Pitrou pit...@free.fr added the comment:
I content that in normal code, it is so extremely rare as to be
unheard of, to get exceptions about the parser stack overflowing or
segfault the compiler by too deep nesting. People who are doing this
(generally to prove the point about
R. David Murray rdmur...@bitdance.com added the comment:
This is a purity versus practicality argument. I agree with both sides :)
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11343
Antoine Pitrou pit...@free.fr added the comment:
This looks like a rather good idea, although I'm not sure it deserves a new
global exception type.
--
nosy: +benjamin.peterson, ncoghlan, pitrou
stage: - patch review
___
Python tracker
Benjamin Peterson benja...@python.org added the comment:
Just make it a SyntaxError.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11343
___
Benjamin Peterson benja...@python.org added the comment:
Oh, I see Martin disagrees. SyntaxError is raised for anything which Python
won't compile. For example, too many arguments gets a SyntaxError.
--
___
Python tracker rep...@bugs.python.org
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +ericsnow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11343
___
___
Python-bugs-list
Andreas Stührk andy-pyt...@hammerhartes.de added the comment:
FWIW, this also affects `ast.literal_eval()`.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11343
___
Andreas Stührk andy-pyt...@hammerhartes.de added the comment:
On Fri, Mar 4, 2011 at 9:30 PM, Terry J. Reedy rep...@bugs.python.org wrote:
I agree with Martin (from 2000) that SyntaxError is not right either. Perhaps
a new ParseError subclass thereof.
I added a new `ParserError` that
Changes by Andreas Stührk andy-pyt...@hammerhartes.de:
Removed file: http://bugs.python.org/file20926/parser_nested_SyntaxError.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11343
___
Changes by Andreas Stührk andy-pyt...@hammerhartes.de:
Removed file: http://bugs.python.org/file20925/parser_nested_MemoryError.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11343
___
Terry J. Reedy tjre...@udel.edu added the comment:
I agree that compile-time stack exhaustion is different from runtime
object-heap exhaustion and could/should have a different error.
I agree with Martin (from 2000) that SyntaxError is not right either. Perhaps a
new ParseError subclass
New submission from Andreas Stührk andy-pyt...@hammerhartes.de:
Currently, if the parser's internal stack is full (as it happens when
the parser tries to parse a deeply nested structure), the parser
writes an error message to stderr and a bare MemoryError is
raised. That way, it is really hard
Changes by Andreas Stührk andy-pyt...@hammerhartes.de:
Added file: http://bugs.python.org/file20926/parser_nested_SyntaxError.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11343
___
35 matches
Mail list logo
