> 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/)
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