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

[Greg Landrum]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.995943227.11347.python-list at python.org...
>
> I'm burned out on the repetition here.  It's not a question of being hard
to
> teach.  It's largely that it's never sensible for
>
>     x = y / z
>
> buried in the middle of some routine to do truncating division if y and z
> happen to be ints but best-possible division if they happen not to be
ints.
[snip]
> This isn't a question of teaching the rules, it's that the specific rule
> here is essentially braindead in a language without static type
> declarations.

When I read these arguments and think about them, I'm unsurprised to find
myself agreeing with Tim and Guido here -- I usually end up agreeing with
those guys.  It *is* odd to have to do something like:
  x = float(y)/z
to get best-possible division in Python.  It would be *nice* to never have
to explain integer division behavior again (well, not quite, it'll have to
be explained to programmers who are used to the old way of doing things).

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 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?
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.

[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.]

-greg