[Edu-sig] re: Types and true division (was Re: strange output)

[Tim Peters]

I'm fortunate enough to get to talk with Guido in person several times per
decade <wink>.  We've talked about Python's division many times, and,
indeed, I share the blame for Python's original decision to make 1/2 == 0,
since Guido picked my brain about numerics at the time, and we both thought
"well, it's good enough in C, and rationals didn't work that well in ABC, so
what the heck ...".

In all the conversations I've ever had with him on the topic, neither
Sherwood nor Pausch came up.  Arthur, you've been told that more times than
I can keep track of, but you still bring them up endlessly.  Yes, what they
said caught Guido's attention at the time, but no, they've had nothing to do
with this since then.  Any mention of them now is at best irrelevant.

Kirby has managed to gain an excellent understanding of the real issues with
division in Python (perhaps because he's listening?):

[Kirby Urner]
> ...
> About div, the technical point is that all the operators *except* div,
> return very close to equivalent answers, even if the types differ.
> In this sense, it matters less for + - and * whether the arguments
> are floats, longs or integers.  Since there're no explicit type
> declarations in Python (as there are in C, from which the original
> div behavior derives), just eyeballing code is *not* necessarily
> going to make div's behavior unambiguous, even if you're a pro.
> So in this case, I'd say we're dealing with a "gotcha" that it
> doesn't pay to beat your head against.  It's still a problem even
> after you master it -- when reading others' code (don't always
> think about what it's like to read and understand your own).
>
> Going to / and // makes division unambiguous again.  The former
> forces a floating point treatment, the latter an integer treatment.

In a polymorphic language without explict type declarations, allowing

    z = x / y

to lose catastrophic amounts of information silently was simply a Bad Idea,
and more so for accomplished programmers than for newbies.  Along the way,
we changed Python 2.2 so that x**y no longer raised an exception when x and
y happen to be integers and y < 0, and for exactly the same reasons.  They
have nothing to do with newbies, apart that from giving a bizarre result for
sensible inputs isn't truly helpful to anyone.