> [Guido] > > That's your choice. Wildly inaccurate is sometimes unavoidable. This > > is clearly an issue open for debate, but note that I speak from > > experience: ABC used rationals unless you forced it to use reals, and > > the rationals *did* cause real users to complain about how slow ABC > > was. [Moshe] > Well, experiences differ. I'm on the Scheme48 (which uses rationals) mailing > list, and nobody ever complained. Besides, if "forcing" is simply saying > either inexact() (and note that inexact-exact operations are performed > inexactly) or mixing in an inexact literal (assuming that's what 1.0 will > be), it might be easier. I don't know ABC well enough to say how the > forcing mechanism worked. Scheme has no real users -- only CS types. :-) ABC's forcing was as simple as writing ~x or mixing inexact numbers. We did have the notion that 1.0 was an exact literal (to me it looks exact!) so maybe that was an additional problem. > [Guido] > > I think this deserves very explicit mention in your PEP. An example > > of how I would go about implementing my own Rational class or > > extension type would help. > > Well, I don't see why there should be a difference from what happens > currently. The thing is, the model will not support you telling it > at runtime what the results for operations on types it already knows > should be: that would make us Scheme, not Python. Agreed. I think what makes me feel uneasy is that your proposal assumes that there is One True Numeric Type, and all the rest are second-class numbers. Python currently makes no such claim: there are many numeric types built in and you can add your own types that play along. The only thing that makes a difference is that there are literals for the built-in types and not for the extension types; but apart from that they have all the same privileges, and the coercion rules work in everybody's favor (except when they don't :-). Placing more emphasis on One True Numeric Type runs a risk of discriminating against the others. > [Guido] > > Also, the coercions PEP is still in need of an author. Maybe you want > > to take this on too? It will help your numeric proposal if you can > > write down how you think coercions should work. > > Smooth, real smooth. OK, sold to the highest bidder -- I take it. > I'll update it and 0000, and start reading MAL's pages. OK, it's a deal. But make yourself a co-author with MAL. --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