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

[Steve Holden]

[posted & mailed]

" <guido at python.org> wrote ...
> "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!

As another who has argued in the past against the PEP, my major contribution
in recent days has been to simply not post: I had made my views known, and
the volume on this one topic has been frightening without "me too" responses
or knee-jerk criticisms. Not to mention the personal aspersions, which I
found to be completely uncalled for and unwarranted.

So. I would like to say that this current change proposal is certainly the
best I have seen to date. It's never seemed unreasonable to me to want a
float result from the division of two integers. I've probably been using
int-only too long for it to seem *comfortable* to me, but I can accept that
those from non-computer disciplines would prefer results in which (a/b)*b ~
a whichever numerical domain is being used. The code major point at issue
was code breakage. It seems that issue has now been satisfactorily
addressed.

No change of this nature is ever going to be entirely comfortable, and I can
foresee that some of my own code is going to need fixing up.

so-i'll-shut-up-now-and-prepare-to-do-it-ly y'rs  - steve
--
http://www.holdenweb.com/