proposed language change to int/int==float (was: PEP0238 lament)

[Paul Svensson]

"Terry Reedy" <tjreedy at home.com> writes:

>> The interesting thing is that the one thing that has to change in
>> order to get a unified numeric model, whether we introduce rationals
>> in the numeric tower or not, is integer division
>
>(IMO -- and attempting to be helpful again) This (and similar
>statements) is rhetorically wrong and counter-productive.  In PEP238,
>you are NOT proposing to delete integer division (and I hope/presume
>you never will), you are NOT proposing to switch it to C's version
>(ditto), nor are you proposing any other substantive change (ditto).
>From a technical viewpoint, you are merely, in Tim's words, proposing
>to change it's spelling, so that future i//j == current i/j, down to
>the very last bit.

This is not what's proposed.
i//j will be for all numeric types like current i/j for ints.
i/j will be for all numeric types like current i/j for floats.

>The *really* interesting thing is that the one thing that has to
>change for you to pursue your further numeric goals is the current
>overloading of integer and fractional division onto one symbol, which
>is exactly what 238 undoes by adding a second symbol.  The main
>practical technical issue, to repeat from my essay of two weeks ago,
>is code breakage, forwards and back, and the costs and benefits
>thereof.

The important thing is that i//j will return the same value
regardless if i and j ar ints or floats; ditto for the new i/j.

Numeric unification means that (i == x and j == y) == (i op j == x op y)
for all op, i, j, x, y, regardless of numeric type
(ignoring exceptions and round-off errors).

This is not true for the current semantics of '/'.  That's why it must go.

	/Paul