[Python-Dev] shouldn't we be considering all pending numeric proposals together?

[Guido van Rossum]

> I just "discovered" the loooong threads on c.l.p about PEP 238 --
> looks like Guido is getting flamed badly here and I certainly don't
> want to add to this, so just to summarize my previous post: the
> only issue I have with PEP 238 (and all other PEPs trying to change
> basic numeric properties in wild ways ;-) is backwards compatibility.
> 
> IMHO, these are all great feature to have in a nice language, it's
> just that the path to these features should be carefully laid
> out and this is probably *much* harder to get right than the
> features themselves.

Yup, and that's what I'm focusing on in my responses.  I plan to lay
out a very careful compatibility track and discuss *that* with the
community in earnest.

> BTW, I intend to make the mxNumber types subclassable once the
> dust has settled over the PEP 253 (subclassing builtin types) 
> et al. features. 

Very cool.  All extension types should be subclassable!  (Also all
built-in types.  But that's my job. :-)

> I believe that this should provide a nice base for experimenting
> with rationals, long integers, etc. For example, it might turn
> out that having int / int create a rational number would
> solve most of the problems mentioned on the various threads about
> PEP 238 since rationals don't lose precision and simply defers the
> conversion to either integers or floats to the point where one of
> the two interpretations is actually needed by the code, e.g.
> an "i" parser marker will invoke truncation to an integer while
> float(result) will apply the conversion to a floating point 
> number. If we make rationals a subtype of integers we wouldn't
> even have PyInt_Check() problems at C level.... hmm, I'm getting
> carried away.

For the folks concerned about code breakage, it doesn't make much of a
difference whether 1/2 returns a float or a rational -- in both case
the integer division property that they want is broken.

I actually expect that most conversion jobs will be easy -- all those
folks who suffer from "Extreme Fear of Floating Point" (as Tim calls
it) can simply change every / into a // in their program (using a tool
that properly tokenizes) and they should be done, since most likely
their code never uses floating point. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)