A use for integer quotients

[Timothy Docker]

Guido van Rossum <guido at python.org> writes:

> Reiterating why the current definition of '/' is evil: int and float
> together aren't really two distinct types: they are at most a
> type-and-a-half, and the integers are embedded in the space of floats
> for most practical purposes.  Division is the one exception, and it
> hurts.  Nobody wants to write polymorphic code where '/' means
> truncated division for int arguments but fractional division for float
> arguments.  You know which kind of division you want when you write
> the code, but there's no way to spell it.

There certainly is a need to "spell" these two operations
independently.

I accept that the choice of '/' for a float result, and '//' for an
integer result may be the most logical and intuitive for newcomers
to the language. In a new language this would be the desired choice.

However, as everyone realises, this proposed approach breaks code
relying on the old spelling for integer division. Given this, I would
be in favour of the suggested reverse situation where '//' implies a
floating result. Why have there been no comments on this?

> Of course, I'm well aware of the issues around maintaining old code.
> We will have to carry around "from __future__ import division" for a
> loooooong time.  Python 2.2 is the first opportunity to introduce it,
> so let's not be shy.

I haven't read every message in the threads, but no-one advocating the
change has suggested a mechanism for supporting a code base compatible
with old and new releases. In my applications I make use of several
modules which are supported across multiple releases, including
OmniORB (thanks Duncan!), and Sybase (thanks Dave!). I wouldn't want
the jobs of these developers to get any harder.

Tim