2008/1/7, Raymond Hettinger <python at rcn.com>: > Arghh! You seem hell-bent on jamming this in. Please leave the > decimal module alone. It does *not* need both a round() method > and a quantize() method. Question. I'm so used to quantize that I don't care. And I'm, in general, -0 to adding new methods to Decimal and/or Context. But in Py3, when you make round(x), x.__round__ will be executed. Same with trunc, ceil and floor. And I think that Decimal should grow these __xxx__ methods. Having said that, the only thing that is not clear to me is if we should: - Diverge 2.6 and 3.0 decimal.py code - Add these __xxx__ to 2.6, and have still one code of decimal. Guido voted for this last one, in the issue 1623: """ If there aren't too many differences between the 2.6 and 3.0 version of decimal.py and your patch, do 2.6 first, then the next time we merge stuff into 3.0 from the trunk it'll be forward-ported automatically. """ But, in the light of this thread, and the new PEP that you will be writing, I think that now it's time to decide this. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
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