proposed language change to int/int==float (was: PEP0238 lament)

[Terry Reedy]

"Guido van Rossum" <guido at python.org> wrote in message
news:cp66chbobw.fsf at cj20424-a.reston1.va.home.com...
> "Chris Gonnerman" <chris.gonnerman at newcenturycomputers.net> writes:
> >     4.  Difficulty in writing backwards-compatible code is bad
> >         (thus, code to implement partitioning of a dataset would
> >         naturally use the // operator in 2.2+ but would not be
able
> >         to in pre-2.2, so the div() function would have to be
> >         religiously used, hurting readability).

> Hm, #4 is relatively new in this discussion (for me, anyway).  I
will
> have to adapt to this new requirement, which I find reasonable
> (although I wish it didn't exist -- but I understand the
motivation).

My solution for this:

Since int/int and float//float will have new meanings, don't use them.
Write float(int)/int and floor(float/float) instead to get the new
meaning.  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.

This is not the same as having *one* file that is cross-compatible,
but since the generation of the second is automated, it is certainly
close.  A version check could be inserted in both versions (and
automatically modified) to make sure that each version of the file
only runs on versions of the interpreter it is compatible with.

  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