[issue11343] Make errors due to full parser stack identifiable

[Benjamin Peterson]

Benjamin Peterson <benjamin at python.org> added the comment:

2011/7/16 Nick Coghlan <report at bugs.python.org>:
>
> Nick Coghlan <ncoghlan at 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 should do.
>
> Some kinds of errors are inherently implementation specific
> (MemoryError and SystemError spring to mind). No sane implementor is
> going to try to match CPython like-for-like when it comes to those.
> SyntaxError, however, is typically defined by the language definition,
> not the CPython implementation of it. By introducing a new exception
> type, we're explicitly telling other implementations "Look, this is
> our problem that we don't plan to fix as it doesn't typically arise in
> real code, but please don't deliberately cripple your own
> implementation just to match this behaviour". I'm strongly with MvL on
> this one - SyntaxError itself should never be raised for legal Python
> code just because the CPython bytecode generation toolchain isn't able
> to handle it properly.

Implementations are quite good at figuring this stuff out themselves.
We don't need a whole new exception (new docs, one more thing in the
builtin namespace) to "send a message" to other implementations. If
some implementation is not part of the language, then its test just
just be marked cpython_only. It shouldn't be brought into public API
and the language.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________