PEP 238 (revised)

Andy Salnikov salnikov at
Fri Jul 27 01:27:01 EDT 2001

  Well, what I see is a strong determination to get this PEP through. It's
unwise to continue arguing under these conditions, but anyway... Don't take
it personally, I understand pretty much your ideas to make this world nicer,
the only thing I do not like is the burden you put on all your Puthon
programmer guys.

"Guido van Rossum" <guido at> wrote in message
news:cp4rrz5onj.fsf at
>     We propose to fix this by introducing different operators for
>     different operations: x/y to return a reasonable approximation of
>     the mathematical result of the division ("true division"), x//y to
>     return the floor ("floor division").  We call the current, mixed
>     meaning of x/y "classic division".
  It's very much like in any PR company, giving it tag of "true division"
seems to imply that this is the only way to do division correctly:) I think
there is no more truth in it than in the classic. (Just my opinion, and its
useless to debate about what truth is, it's rather ethical cathegory, has
nothing to do with division operator.)

>     - 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.
  How is it? The x//y is supposed (in this only suggestion) to do exactly
the same as x*1.0/y. Please, correct it.

  I still do not see a word about what it does to migrate all the existing
code, what you do and what Python coders do, the tools we should expect,
time scale. Would be nice to have complete understanding of these issues
_before_ we get into the boat.


More information about the Python-list mailing list