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