A way to accommodate laguage changes

[Paul Boddie]

"Terry Reedy" <tjreedy at home.com> wrote in message news:<5E877.23798$EP6.5677355 at news1.rdc2.pa.home.com>...
> 
> 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.

I assert that list comprehensions, nested scopes, generators and
type-class unification features are interesting, but not compelling
enough functionality to persuade most developers to upgrade. Augmented
assignment and iterators are arguably more compelling, but one is
hardly taking on the role of "computer language hermit" by rejecting
them in Python.

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

I don't think the most significant problems raised in the currently
predominant discussion of the division operators, for example, have
anything to do with running newer code on older releases, unless you
are indirectly attempting to address the issue of how people running
older releases of Python, because they want the original division
semantics, can actually run the modules and extensions released for
later releases.

"from __past__ import" anyone? ;-)

Paul