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

[M.-A. Lemburg]

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.

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

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.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/