A way to accommodate laguage changes

[Terry Reedy]

"Paul Boddie" <paul at boddie.net> wrote in message
news:23891c90.0107240128.4715d705 at posting.google.com...
[responding to me]
...
> 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

That is an issue for each developer to decide in the context in which
he works.
For myself, I may jump for generators (and iterators in general).

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

I agree.  I think the worst problem is the silent breakage of old,
unmaintained code run on new releases.  This is a problem specific to
a semantic change such as that proposed.  I wrote the above, in
response to two people who raised the issue, precisely to show that
running new code on old releases is a lesser problem.

> "from __past__ import" anyone? ;-)

I agree this would be nice, but it will not, in itself, save old code
lacking  this.

Terry J. Reedy