proposed language change to int/int==float (was: PEP0238 lament)
Guido van Rossum
guido at python.org
Wed Jul 25 06:25:49 CEST 2001
"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
> [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.]
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-list