Comment on PEP-0238

[Emile van Sebille]

No objection here.

Why not:
from __future__ import non_integer_division


FYI:  I asked my 10-year-old daughter last night what 24 divided by 5 is.
She said 4 remainder 4.  I asked what 1 divided by 2 is.  She said .5.  My
6-year-old daughter piped in with 0 remainder 1.

--

Emile van Sebille
emile at fenx.com

---------
"Guido van Rossum" <guido at python.org> wrote in message
news:cpsngaja4g.fsf at cj20424-a.reston1.va.home.com...
> Roman Suzi <rnd at onego.ru> writes:
>
> > This is reasonable. However, IMHO, solution need to be different
> > than redefining established "/" behaviour?
> >
> > Could "right" division be given some other symbol than "/" and old "/"
be
> > left intact as a "low-level" C-conformant division every Python
programmer
> > is accustomed to?
>
> Unfortunately, the number of potential Python programmers who will be
> frustrated by the current integer division is much larger than the
> number of established Python programmers.  The sooner we fix this the
> better!
>
> Another thing.  Division of integers is a pretty uncommon operation
> (less common than shifting or bitwise masking, in my experience).  As
> an experiment, I added a warning to int and long division, and ran the
> test suite.  The result: 44 distinct warning locations, of which 38
> were part of the test suite (more than half of which had to do with
> the testing of division or binary operators, or used 1/0 to raise an
> arbitrary exception).  In the library itself, only three modules
> engaged in integer division during execution of the test suite:
> bisect, dumbdbm, and inspect.  Of these, bisect and dumbdbm will need
> to be converted to using div(); inspect uses 1/0 to raise an
> exception.
>
> The warning framework and the future statement are there to make the
> transition easier.  Here's my plan, "new division in four phases":
>
> 1. First we introduce a new function div() and a future statement that
>    makes integer division return a float result for a specific module.
>
> 2. In a following revision, we add a warning when / is used on two int
>    or long arguments, recommending to use div() instead.  (It is
>    important not to start warning in phase 1, so folks have time to
>    switch to div() voluntarily first; maybe phase 1 could have a
>    command line option to warn about integer division.)
>
> 3. A revision later, we change all plain integer divisions to be an
>    error, *forcing* folks to use div() or use the future statement to
>    specify floating point division.
>
> 4. Finally we can implement the "future" behavior by default.
>
> I haven't picked dates yet; if folks agree, I would like to add div()
> and a future statement to 2.2 and space the other steps a single
> revision apart, so phase 4 would be at Python 2.5 (April 2003, if we
> keep the current release schedule up).  Is that too aggressive?
>
> I currently favor div(x, y) over x//y and x div y.  Maybe also add
> mod(x, y) for symmetry (that would also explain divmod() as a
> messenger from the future :-).
>
> I'm not sure how to spell the future statement.  Here are some
> choices:
>
>   from __future__ import float_division
>   from __future__ import real_division
>   from __future__ import new_division
>   from __future__ import division
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)