Radical Suggestion for Integer Division Migration

Carl Banks idot at vt.edu
Fri Jul 27 20:53:54 EDT 2001


Basically, have all integer division using the "/" operator throw an
exception during the transition period, unless "from __future__ import
division" appears in the module.  

A little PEPish explanation follows.  (Only the abstract is much too
baroque....)



Abstract

    Many people do not like the new division semantics introduced in
    PEP 238, for it bears the curse of a backward-incompatible
    language change, shrouded by the cold repression of Silence.  It
    is Silence that people fear most about this transition, for
    Silence harbors the subtle code breaks that shall arise, lurking
    in unconscious shadow, waiting in ambush.

    Thus, it is suggested that Python save us from this pernicious
    evil by vanquishing Silence.  For then, the program that attempts
    to divide two integers shall invoke the great and terrible wrath
    of Python, and lo! Python shall raise an IntegerDivisionError
    exception, casting light upon the shadow in which tomorrow's
    subtle bugs hide.  And only by switching to the integer division
    operator "//", or by including "from __future__ import division"
    atop the module, can the programmer abate Python's fury.

    Yet it is written: Upon the change of the major version number,
    Python's tenacious wrath shall relent, and thenceforth all shall
    live peacefully in the fertile land of consistent division.


Motivation

    PEP 238 proposes a rather controversial language change to Python,
    namely a change in the semantics of the division operator.  But,
    as Tim Reedy pointed out in the c.l.py post introducing the
    "Language Change and Code Breaks" thread, a change in semantics
    that does not produce an error (like PEP 238) can lead to subtle
    breakages in code.

    PEP 238 does include a provision to produce a warning when integer
    division occurs.  Warnings, however, are often too easy to ignore.

    It goes without saying that we would like all Python code to be
    ready when Python 3.0, and the new semantics, arrive.  It seems
    that, as long as the classical semantics for integer division
    remain the default, much code will continue to use it, right up to
    the release of 3.0.  This, of course, could lead to subtle bugs.

    This proposes that, in the transition period, there be *no default
    semantics at all* for integer division.  Integer division using
    "/" would become illegal, throwing an IntegerDivisionError
    exception, unless the programmer explicitly requests the new
    semantics with "from __future__ import division."  Because of this
    exception, the subtle errors that might have resulted would instead
    manifest themselves as glaring exceptions, easy to see, and easy
    to fix.  Older code would not fail silently during the transition
    period, but fail resoundingly.

    Hopefully, by the advent of Python 3.0, all Python code will
    account for the new semantics.


Specification

    Starting with Python 2.3, an attempt to divide two integers
    (including long integers) would result in an exception,
    IntegerDivisionError, being raised.  The IntegerDivisionError
    exception would display a helpful message, such as:

        Integer division is in a transition period in Python, and is
        currently disabled.  You can use the new integer division
        operator "//" instead, or you can put "from __future__ import
        division" at the beginning of the module to request the new
        division semantics.

        Note that modules designed for Python versions before 2.3 may
        no longer work.  It is suggested that you upgrade any modules
        you are running, and review any uses of division in your
        programs.

	For more information, see http://blah.blah/blah/blah.html

    Although the above message is much longer than the typical
    one-line messages for most exceptions, in this case it is
    justified because of the potential for code break that can result
    if one ignores it, and the possibility that someone running Python
    2.3 for the first time might not be aware of the upcoming changes.

    And, as the helpful error message says, one can use the new
    integer division operator to perform integer division.  Or, one
    could request the new division semantics by including 'from
    __future__ import division' atop the module.

    Non-integer division would not throw an exception.

    The IntegerDivisionError would only exist in the transition
    period.  In Python 3.0, the new division semantics would become
    the default, and IntegerDivisionError would disappear.


P.S.

    If this seems to have any chance at all, I'll write up a real PEP.

P.P.S.

    I'd like to vote for "quotient" as a substitute for integer
    division, even though it's wrong.

P.P.P.S.

    Also, may I request that, since we've already decided we're going
    to break division in 3.0, we might as well break everything else,
    too.  Let's figure out everything that needs fixed (type/class
    dichotomy, heterogenous comparison, ";".join, etc.), and get it
    out of the way all at once.



-- 
CARL BANKS



More information about the Python-list mailing list