[Edu-sig] More spillover re the division PEP

[Kirby Urner]

>
>I think the simple, deciding factor on the issue is whether or not most 
>programs (and progammers) need or expect an equation like "1/2" to 
>evaluate to 0. If 0 is the "correct answer" in a majority of situations, 
>then the current behavior should stay. However, if 0.5 is the "correct 
>answer" in a majority of situations and many programmers are thus writing 
>"division
>functions" to type-check and convert arguments to ensure this answer is 
>returned, then the behavior needs to be changed.

<<SNIP>>

>Kevin

Well, I think you're in the majority, plus the BDFL agrees,
so by 3.0 looks like we'll be having / do type conversion as
needed.  Note that you don't have to do type checking
before converting, if you know it's a number -- if you don't
know, i.e. it might be a string, then you have to type
check anyway, or catch the exception -- i.e. float(a)/b
is sufficient to return a float result, and is self-
documenting as to programmer intent.  Another idiom is
(x*1.)/y -- you don't type check before executing (if x
was already a float, so what).  If you're going to be using
these variables a few times, coerce 'em up top, like when
declaring variable types in other languages e.g.

     # int [float] -> float
     x *= 1.
     y *= 1.
     ...
     r = x/y

1/2 = 0.5 is the behavior most expect from their calculators,
where int-type division ala Python doesn't occur (you might
get fractions in p/q format, but those are 'rationals' not
'floats').

I probably shouldn't be so nostalgic for the status quo.
After all, I do a lot of coding in Xbase (?), e.g. VFP (?)
and that's a weakly typed interpreted language like Python,
and is case insensitive (as Guido has proposed for Python,
but given up on) and it evals 1/2 the way Python is going
to soon (i.e. 1/2 = .5).  It'll be very familiar territory
(same for a lot of other programmers, coming from other
languages where this is the norm).

Kirby