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

[Terry Reedy]

> Right!  In fact, the goal of PEP 238 is to make such a redesign of
> Python's numeric system possible

Saying this explicitly makes explicitly obvious what to me was not,
before:-).  Even though I do not currently care about such a redesign,
but you do, I consider the above a point in favor of 238.

(I am assuming that such a redesign would not break 'regular' floating
point code, such as Newton's method, that does not depend on every
last bit being just as it currently is to run correctly.)

I think another, currently less-well-articulated goal/result of 238 is
that it will make it possible for you to pursue your CP4E dream
project without forking Python and also without needing to make
further disruptive changes to the core.  If you agree with the last
proviso, then I also consider this a point in 238's favor.  I think
more could be said about the connection that would make what's obvious
to you clearer to others.

> 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. (I am ignoring any possible effect of int/long
unification, which is a completely separate issue.)  So to ask another
rhetorical question:  why frighten people unnecessarily? or futilely
attempt to get them to accept something that you are not proposing
(and I hope/presume you never will)?

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 the one thing you need from people in
order to make 238 work without forking Python is their agreement (for
whatever personal reason) to do the respelling and absorb the cost in
return for the expected long-term individual and collective benefits.
You do not need, and will never get, general agreement on the
metaphysical relationships of abstract (count, integer, rational,
real) and concrete (int, long, float) number sets.  Ditto for the
abstract virtue or esthetics of various combinations of type-dependent
division rules.

Terry J. Reedy