[Edu-sig] RE: PEP0238 lament

[Tim Peters]

[Arthur_Siegel@rsmi.com]
> ...
> If I was told that experinced programmers might
> appreciate this change for any possible reason -
> I'd be quiet as a mouse.

Not all experienced programmers agree.  At the last Python Conference, I
moderated a 40-some person group discussion on conceivable changes to
Python's numeric model, not advocating but keeping the participants from
killing each other <wink>.  The meaning of integer division wasn't the
focus, but naturally came up.  By show of hands, about 3/4ths of the
participants agreed that 3/4 should not return 0, but rather *something* x
such that x*4 had a better chance of being confused with 3 than with 0.
There was no consensus on exactly what 3/4 should return -- rational or HW
float or decimal float were the most popular alternatives.

It shouldn't be so hard to understand why.  The current integer division
loses information silently and without a trace.  Combined with that Python
is not a statically typed language, there's simply no telling what e.g.

def velocity(distance, time):
    return distance / time

will compute by inspection.  This isn't about esoteric user overloading of
"/", it's about ordinary arithmetic on builtin numeric types, and many
experienced Python programmers have testified over the years to being burned
in practice by stuff exactly that simple.

I expect that either way is easy enough to *teach*, but I don't accept ease
of teaching as a primary goal:  I'm much keener on semantics that, once
*learned*, are hard to forget or to stumble over.  Even if such semantics
are 100x harder to teach at first, fine by me:  you spend the rest of your
life living with the consequences.  I wish the definition of continuity were
easier to teach too, but that doesn't mean I'll settle for an easier
definition that doesn't actually work <wink>.

some-mice-are-surprised-when-thet-divide-up-the-cheese-and-
    cheese-mass-mysteriously-disappears-ly y'rs  - tim