PEP0238 lament

[Bengt Richter]

On Sun, 22 Jul 2001 14:22:21 -0400, "Tim Peters" <tim.one at home.com> wrote:

>[Arthur_Siegel at rsmi.com]
>> ...
>> If I was told that experinced programmers might
>> appreciate this change for any possible reason -
>> I'd be quiet as a mouse.
>
I'd call myself experienced, though not yet with Python (though
I fancy my other experience gives me a leg up on most Python newbies).

I am generally so adaptable it's almost a problem, so I'll
have no big problem with '//' after I accept that this is Rome,
and I should do as the Romans do. It's certainly not going
to put me off Python ;-)

>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
The thing is, current floating point operations also (sometimes, not always,
just as with integer ops) lose "information silently and without a trace."
Just less noticeably, for the most part, if you sanitize output.

Which leads me to wondering if exactness would be a more approachable
concept for CP4E than details of numeric representation alternatives.

For many 'float' is about as relevant to their desired computing experience
as 'hypoid' is to their commuting experience. Why not keep both hidden under
the hood (without welding it shut, of course) ?

>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 believe you. BTW, is there an efficient type assertion that doesn't go away with
optimization, that one could use to refuse wrong-type arguments?

>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
Glad to hear that. <rant>Worst IMHO is when teachers teach what is actually wrong
to children or the otherwise innocently ignorant, with the rationale that
the real truth is too complicated, and even letting on that there is a real
truth will just be confusing. That not letting on part is the real evil.
Of course, many teachers are themselves the product of this methodology,
and pass it on unawares.</rant>

I wonder what K-12 teachers will say about Python float ;-/
Maybe there should be guidelines for teaching what is not understood,
so that bright kids don't get cynical too fast.

>*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>.
>
You teach that? How many are you, anyway? ;-)