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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4