Future division patch available (PEP 238)

[Stephen Horne]

On 22 Jul 2001 22:17:10 GMT, m.faassen at vet.uu.nl (Martijn Faassen)
wrote:

>Moshe Zadka <moshez at zadka.site.co.il> wrote:
>> On Sun, 22 Jul 2001, Robin Becker <robin at jessikat.fsnet.co.uk> wrote:
>
>> [about //]
>>> it just looks awful as well as annoying those who don't want this
>>> change.
>
>> Any solution would have annoyed the other side, and one solution
>> had to be taken.
>> And no, "inertia" isn't an excuse. Python cannot be ruled by inertia,
>> just as it cannot arbitrarily break backwards compat. 
>
>People just differ in their opinions on what is inertia and what is
>arbitrarily breaking backwards compatibility. Robin is probably in
>the "arbitrarily breaking backwards compatibility" camp on this issue,
>while you're in the "inertia" camp. I'm in the "just leave me here,
>go on without me, I'll be okay" camp, myself.

This is not *arbitrarily* breaking backwards compatibility - it is
*irrationally* breaking backwards compatibility.

Division on integers should be integer division. It is natural to have
an integer result and a remainder - that was what people did for
thousands of years before the idea of fractional parts was even
thought of. Many measures are inherently integer, and it is a simple
fact of life that you have to deal with the integer result and the
remainder.

Mathematically, integer division should be the inverse of integer
multiplication, with no extra functionality bar the need to allow for
the remainder. Well shock horror - that's exactly what we've got now
and exactly what we're throwing away.

Integer division is important to a huge range of applications -
anything involving money stands out as the obvious case, but also
cryptography and others.

These are all valid viewpoints for keeping integer division exactly as
it is - completely independent of the code breaking issue. Therefore,
the idea that 1/2 should give 0.5 is a matter of opinion - not an
ideal.

If you want float results, use float arithmetic - it's simple, it
works and it does *not* break existing source code.

If you really want a division operator that treats everything as
floats, then *that* is the new functionality and *that* should be the
new operator. I don't mind such an operator being added - I will
simply feel free to ignore it.

Python would be a laughing stock without a division operator, and it
will certainly be a laughing stock if we can't rely on it to do the
same thing from one release to the next. It's a far to fundamental
change just to please people with a particular mindset.

And lets remember - even people *with* that mindset are going to have
problems - they *must* have code with integer division or they would
never have noticed the result being an integer.