# [Python-Dev] Changing the Division Operator -- PEP 238, rev 1.12

**Ka-Ping Yee
**
ping@lfw.org

*Fri, 27 Jul 2001 16:37:08 -0700 (PDT)*

This all looks pretty good! Nice work, Guido -- especially given the
minefield of compatibility issues you have been tiptoeing through.
On Fri, 27 Jul 2001, Guido van Rossum wrote:
>* - Overloaded operator methods:
*>*
*>* __div__(), __floordiv__(), __truediv__();
*
I'm concerned about this. Does this mean that a/b will call __truediv__?
So code that today expects a/b to call __div__ will be permanently broken?
I think you might want to provide a little table in the PEP. Here is my
stab at describing the current proposal, so you can correct it:
in Python 2.1 in Python 2.2 in Python 3.0 [*]
/ on numbers classic division classic division true division
// on numbers nothing floor division floor division
/ on instances __div__ __div__ __truediv__?
// on instances nothing __floordiv__? __floordiv__
/ API call PyNumber_Divide PyNumber_Divide PyNumber_TrueDivide?
// API call nothing PyNumber_FloorDivide PyNumber_FloorDivide
/ AsNumber slot nb_divide nb_divide nb_true_divide?
// AsNumber slot nothing nb_floor_divide nb_floor_divide
/ opcode BINARY_DIVIDE BINARY_DIVIDE BINARY_TRUE_DIVIDE
// opcode nothing BINARY_FLOOR_DIVIDE BINARY_FLOOR_DIVIDE
[*] or in Python >= 2.2 with "from __future__ import division"
I'm thinking that nb_true_divide and __truediv__ should be replaced with
just nb_divide and __div__ in the above table.
>* Semantics of Floor Division
*[...]
>* For complex numbers, // raises an exception, since float() of a
*>* complex number is not allowed.
*
I assume you meant "floor()" here rather than "float()".
-- ?!ng