Issue 22900: decimal.Context Emin, Emax limits restrict functionality without adding benefits (original) (raw)

Issue22900

Created on 2014-11-19 11:51 by Jure.Erznožnik, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (2)
msg231374 - (view)	Author: Jure Erznožnik (Jure.Erznožnik)	Date: 2014-11-19 11:51
At some point since Python 2.7, the EMin, Emax members got more restrictive bounds. Emin cannot go above 0 and Emax cannot go below 0. I would argue against this logic: .prec specifies total precision .Emin and .Emax effectively limit possible locations of decimal point within the given precision. Since they don't specify / enforce EXACT position of the decimal point, what's the point of limiting them? Without restrictions, setting Emin = Emax = some positive number effectively restricts number of decimal places to exactly that positive number without a need for separate (and expensive) .quantize() calls. Removing this restriction provides an option to use decimal as true fixed-point arithmetic.
msg231375 - (view)	Author: Alyssa Coghlan (ncoghlan) *	Date: 2014-11-19 12:09
I would expect this to be a difference between the original pure Python implementation and the current C accelerated implementation. The constraint is in alignment with the General Decimal Arithmetic Specification that the decimal module aims to implement, which requires that Emin and Emax define a balanced range about zero. (That is, Emin = -Emax +/- 1) The fact the pure Python implementation didn't enforce that constraint was an implementation detail - other implementations (including the cdecimal module, which was incorporated into the standard library to provide CPython's C accelerated version in Python 3.3) are free to enforce it.