[Raymond Hettinger] > ... > My intention for the module is to be fully compliant with the spec and all of its > tests. Code written in other languages which support the spec should expect > to be transferrable to Python and run exactly as they did in the original language. > > The module itself makes that promise: > > "this module should be kept in sync with the latest updates > of the IBM specification as it evolves. Those updates will > be treated as bug fixes (deviation from the spec is considered > a compatibility, usability bug)" > > If I still have any say in the matter, please consider this a pronouncement. Tim, > if you're listening, please chime in. That was one of the major goals in agreeing to adopt an external standard for decimal: tedious arguments are left to the standard creators instead of clogging python-dev. Glad to see that's working exactly as planned ;-) I'm with Raymond on this one, especially given the triviality of implementing the revised spec's new logical operations. I personally wish they would have added more transcendental functions to the spec instead. That's bread-and-butter stuff for FP applications, while I don't see much use for the new "bit" operations. But if I felt strongly enough about that, I'd direct my concerns to the folks creating this standard. As slippery slopes go, this less than a handful of trivial new operations isn't steep enough to measure, let alone cause a landslide.
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