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

Terry Reedy tjreedy at
Thu Jul 26 05:03:20 CEST 2001

"Guido van Rossum" <guido at> wrote in message
news:cp66chbobw.fsf at
> "Chris Gonnerman" <chris.gonnerman at> 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
> >         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
> have to adapt to this new requirement, which I find reasonable
> (although I wish it didn't exist -- but I understand the

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

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

More information about the Python-list mailing list