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