PEP 238 (revised)

[Mark Day]

In article <cp4rrz5onj.fsf at cj20424-a.reston1.va.home.com>, Guido van
Rossum <guido at python.org> wrote:

> Semantics of Floor Division
> 
>     Floor division will be implemented in all the Python numeric
>     types, and will have the semantics of
> 
>         a // b == floor(a/b)
> 
>     except that the type of a//b will be the type a and b will be
>     coerced into.  Specifically, if a and b are of the same type, a//b
>     will be of that type too.

I assume that means type(long//int) == type(int//long) == long.

Can we assume that when both arguments are integers (including long
integers), that the result is exact (and that no part of the
computation involves conversion to floats)?  That is, would we get the
same result as "classic" division?

>     - Let / keep its classic semantics; introduce // for true
>       division.  This doesn't solve the problem that the classic /
>       operator makes it hard to write polymorphic numeric functions
>       accept int and float arguments, and still requires the use of
>       x*1.0/y whenever true divisions is required.

I don't understand this statement.  Wouldn't you use // when you wanted
true division?  Why wouldn't // (true division) support polymorphic
functions?

All I can see that's missing (compared to the actual proposal) is floor
division that returns the same type as the (coerced) arguments.  That
seems like it wouldn't be *too* hard: just use classic division (/ in
this case) and if the result wasn't an integer, just call floor().  I
suppose you could modify floor() [yuck!] or introduce a new function
that returns the same type as its operand.  Is it that important to
provide a type-preserving floor division?  (If you're assuming floor
division, wouldn't you also use either int(a/b) or floor(a/b)?)

> Semantics of True Division
> 
>     True division for ints and longs will convert the arguments to
>     float and then apply a float division.  That is, even 2/1 will
>     return a float (2.0), not an int.

Well, then I'd call it Float Division.

This has the downside of loosing accuracy when the arguments are longs
and the result can be expressed exactly as a long.

It would be nice if there was a division that would return exact
results of the same type as the coerced arguments (when an exact answer
is possible in that type).   But that begs the question of what you'd
want in the case of division of two longs that can't be represented
exactly in either a long or a float.  I guess I'd lean towards a long
result (i.e. like classic division).

-Mark