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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4