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

[Guido van Rossum]

"Greg Landrum" <gReGlAnDrUm at earthlink.net> writes:

> And then I start thinking about all the code I've written for
> myself, my former employer and my consulting clients. I *know* I've
> used '/' to do integer (truncating) division in that code
> intentionally.  Of course I have, it's the way things were done.
> Once PEP 238 is implemented and the change in place (v2.3?), a lot
> of that code is going to start producing warnings.

The PEP needs an update.  Here's what I am thinking of now.

- In 2.2, the future division statement and the // operator are
  available, and there's a command line option to turn on warnings for
  int/int and another to make the default for / be a float (i.e. an
  implied future division statement everywhere).  The standard library
  is reworked to make it work with all option values.

- In later versions (timing not yet decided), first the default
  changes to enable warnings on int/int, and then (after at least 2
  years) to enable float division by default, but the command line
  options remain available to reverse the situation.

> The warnings can be used to track down the problems before code actually
> breaks and there will be 2 years in which to do so... that's acceptable.
> 
> I do have a question. The PEP says:
> 
>     If "from __future__ import non_integer_division" is present in the
>     module, until the IntType nb_divide is changed, the "/" operator
>     is compiled to FUTURE_DIV.
> 
>     This is not yet implemented in the Python 2.2 release.
> 
> Okay, it's "not yet" implemented for 2.2.  It's going to be though, right?

Yes; I have a preliminary patch in the SF patch manager (referenced
from the PEP).

> If the change is going to happen, it is going to break some of my
> code and I would like to start tracking down these problems and
> changing my programming habits ASAP.

Yes, you will be able to start changing your habits as soon as 2.2 is
released.

> [I started this message intending to make a very different argument because
> of the code breakage.  Then I re-read the PEP and realized that we are being
> promised at least 2 years to fix things before code breaks.  I'm much more
> comfortable with the PEP now.]

Thanks!

--Guido van Rossum (home page: http://www.python.org/~guido/)