PEP0238 lament

[Tim Peters]

[Terry Reedy]
> ...
> I recently realized that a seemingly-safe change that gives semantic
> meaning to a syntactically valid but previously meaningless construct
> (given the state of the vars) will break code that relies on the
> previously resulting exception.

This is nothing new, and indeed it happens every release:  *nothing* can
change without risk of breakage.  It's not even safe to add a meaning for a
sequence of tokens that was previously a SyntaxError, since Python code can
dynamically compile strings at runtime and branch based on whether compile()
(exec, eval(), etc) raise SyntaxError.  Even fixing gross bugs can break
"working" code.

> ...
> Now make seq*seq mean crossconcatenation and the program may break.
> This raises the issue of whether an exception, in any particular
> circumstance, is defined behavior (which referably should not be
> changed) or the result of undefined behavior (which we should feel
> free to define).

Many such questions have gone unaddressed.  For this particular one,
exception behavior is rarely spelled out in full by the docs, so it's
usually, and speaking strictly, undefined.  In practice, like all other
changes, one of this ilk gets evaluated on the best-guess likelihood that it
will provoke significant breakage.  For example, Python will likely never
change an OverflowError into a SystemError, but it's not rare for
AttributeErrors to turn into TypeErrors, or vice versa, across releases, as
objects grow smarter.