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 > 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 <rep...@bugs.python.org> <http://bugs.python.org/issue11343> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
