Mark Dickinson <dicki...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
