Author skrah
Recipients georg.brandl, mark.dickinson, rhettinger, skrah
Date 2012-07-01.09:42:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1341135749.96.0.451368057832.issue10650@psf.upfronthosting.co.za>
In-reply-to
Content
watchexp was available in rescale() from the beginning ...

http://svn.python.org/view/sandbox/trunk/decimal/Decimal.py?revision=40721&view=markup


... and rescale() was renamed to quantize() in

http://svn.python.org/view/sandbox/trunk/decimal/Decimal.py?revision=40909&view=markup


rescale() was once part of the specification, but had identical semantics to
quantize(), which is not specified to allow unlimited rescaling.


I suppose the original rescale() in the sandbox had watchexp for convenience,
in order to avoid two separate functions.

watchexp made it into quantize(), probably because people thought there is
a need for unlimited rescaling. This may be true, but I'd really prefer to
expose rescale() as the unlimited version then.


While it's unusual to just drop an API without deprecation, I think it's OK
in this instance: Virtually all decimal code I saw needs to be cleaned up
anyway because it uses tons of underscore methods from decimal.py.


The only thing that worries me is that there might be code which *really*
needs unlimited rescaling. Such code could of course also use a temporary
context.


So I propose this: Deprecate watchexp and leave it in the Python version for
one release. The C version won't have watchexp from the start. After all,
PEP-399 allows accelerator modules to implement a subset of the functionality
of the Python version -- sometimes PEPs are a wonderful thing :).
History
Date User Action Args
2012-07-01 09:42:30skrahsetrecipients: + skrah, georg.brandl, rhettinger, mark.dickinson
2012-07-01 09:42:29skrahsetmessageid: <1341135749.96.0.451368057832.issue10650@psf.upfronthosting.co.za>
2012-07-01 09:42:29skrahlinkissue10650 messages
2012-07-01 09:42:28skrahcreate