A use for integer quotients

[Steve Horne]

On Mon, 23 Jul 2001 13:18:38 +0300, Moshe Zadka
<moshez at zadka.site.co.il> wrote:

>On Sun, 22 Jul 2001 23:42:03 -0700, Erik Max Francis <max at alcyone.com> wrote:
> 
>> Or you could not change it in the first place, eliminate the transition
>> period requirement, keep Python's integer division operator consistent
>> with other languages 
>
>non-issue. Many other languages do division correctly - Scheme, Perl and
>Tcl, for instance.

All rarely used languages compared with C, C++, Java, BASIC and
others.

And what do you mean *correctly* - integer division is NOT incorrect,
it is the only form of division that is appropriate for integer
measures. If you are using inherently real measures you should use
floats - not integers.

>> I simply cannot believe that the benefit that will be gained will be
>> worth the price in inconvenience.
>
>Here we must agree to disagree. Guido thinks that the benefits it
>will give to Python readability are big enough, and I happen to
>agree with him.

Are clearly debatable matters of opinion going to continue influencing
basic built-in code semantics? I can propose so many that *nobodies*
old code would work afterwards, and I'll have a seemingly good reason
for every single one.

How about it?

Lets start with indenting. People get upset with this regularly. A
good compromise position would be for Python to require both correct
indenting AND block markers, and to insist that both match up. This
would clearly force everyone to write readable code, and it would
catch both broken indentation AND mismatched markers after editing.
People who rely on block markers can look for them as they scan down
code, whereas people who look for indentation can equally look for
that to.

I propose we put this change as from __future__ in 2.3, and force
*everyone* to comply with it by 2.4 - after all *nobody* could
*possibly* claim I don't have a point, so while we should *listen* to
any opinions to the contrary, we've *obviously* got enough to
justification to go ahead anyway!

As for every single Python program or library ever being broken, what
the hell - we *have* got a transition procedure, haven't we!

I'll have the next everything-killer ready to go into the 2.4
__future__ - after all, if we're going to break code we might as well
get people used to it.

-- 
Steve Horne
Home : steve at lurking.demon.co.uk
Work : sh at ttsoftware.co.uk