PEP0238 lament

[Terry Reedy]

"Barry A. Warsaw" <barry at zope.com> wrote in message
news:mailman.996031845.16386.python-list at python.org...

> Modulo the micro-release number, which is guaranteed to only include
> patches (but no guarantee that such patches won't break your code
:),
> why not just symbolically link oldpython -> python2.0 and
newpython ->
> python2.2 ?  Or just make sure that your old applications, for which
> you cannot afford even the possibility of code breakage, always and
> explicitly use python1.5 or whatever?

Interesting point.  A 'change' in the interpreter by definition
changes the behaviour of some non-empty set of program texts.  So if
one wants to be Six Sigma safe, one should test thoroughly with one or
more versions of the interpreter and then restrict the program to run
under that or those versions.  Something like, I suppose,

import sys
if sys.hexversion not in [17105648] # Python 1.5.2
  print "This critically important program has not been tested to run
correctly under", sys.version
  print "Exiting ..."
  sys.exit()

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.  Consider
...
def sq(a): return a*a
...
def user(b):
  try:
     c=sq(b)
  except TypeError:
    return None
  return number_func(c) # we know c is a number
...

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).

Terry J. Reedy