A way to accommodate laguage changes

[Terry Reedy]

"Chris Barker" <chrishbarker at home.net> wrote in message
news:3B5CB83B.F3B7D51 at home.net...
> 3) So, the big disagreement is over whether the improvement in the
> language resulting from the proposed change is worth the
considerable
> pain it is likely to cause by:
>    A) Breaking old code


>    B) Making it very difficult to write code that can run on old and
new
> version of the interpreter.

This problem, though worse in a way with the division change, is
generic to all language changes.  To run newly written code under old
versions of the interpreter, you have to eschew *all* features added
after the oldest version you want to support.  For 1.5.2, this means
list comprehensions, augmented assignments, nested scopes, iterators,
generators, type-class unification features, and what ever else is
next added.

For the proposed division change, the 'new' meanings will be int/int
and float//float.  So write float(int)/int and floor(float/float)
instead.  Only write int//int or float/float.  With the tokenizer
module, it will then be easy to change all instances of int//int to
int/int (old meaning).  It should even even be possible to have
package installers check sys.version and do this conversion on site as
needed.  For newly written code, the harder problem will be to not use
any of the other neat new features, which mostly *cannot* be
automatically back converted.

Terry J. Reedy