Comment on PEP-0238

[Guido van Rossum]

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/)