[issue8540] Make Context._clamp public in decimal module

[Mark Dickinson]

Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'd prefer to drop the ExtendedContext completely.

We have to be careful not to break existing 3rd party code, though.  A newly-designed decimal module, prepared with 20/20 hindsight, probably wouldn't include an ExtendedContext with the current definition. But we're not dealing with a newly-designed module:  we're dealing with a well-established and well-used module, so there's not a lot of scope for removals or major behaviour changes.

Personally, I don't think the design error (if there is a design error here) is big enough to make it worth breaking backwards compatibility.  I'd rather leave ExtendedContext in for the duration of Python 3.x, but introduce better options and steer (via the documentation) new decimal users towards those.

(BTW, Python takes backwards compatibility pretty seriously:  see PEP 387 for a write-up of the policy.)

> If we make Decimal{32,64,128} contexts available, we should document exactly how the arithmetic deviates from IEEE754.

Possibly, though that's less important to me than just being able to read and write values in these formats produced by other systems.

Were you thinking of any deviations in particular?


Making clamp public should be straightforward enough though, and is independent of the changes discussed above;  I'll see if I can come up with a patch.  (Even here, though, I think it makes sense to leave the private _clamp attribute in place in case people are using it;  a new public 'clamp' property can be added that wraps the _clamp attribute.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________