Stefan Krah added the comment:
It's an implementation detail of decimal.py to represent infinity with
a coefficient of '0' instead of the empty string:
>>> Decimal("inf")._int
'0'
So IMO the tuple representation exposes that implementation detail. I'm
still not sure why that was done or what the benefit was.
For cdecimal, initializing a coefficient for infinity is completely
meaningless, since infinities simply don't have a coefficient.
So the representation DecimalTuple(sign=0, digits=(0,), exponent='F'),
which I took over for compatibility, is factually wrong for cdecimal.
Of course, exponent='F' is also wrong. I don't mind that as much, because
there is a direct mapping to the input strings of the grammar.
I think the tuple representation isn't that useful to begin with. In all
use cases I've seen, people are a) reading the tuple an b) converting the
coefficient tuple back to a Python integer.
So, I'd really like to deprecate the whole interface in favor of either a
read-only interface:
x.sign -> 0 or 1 (perhaps even 1 or -1)
x.coeff -> Python integer
x.exp -> Python integer
If x is special, raise InvalidOperation. People usually need to check for
specials anyhow.
Or a tuple interface with an integer coefficient
(sign=0, coeff=12345, exponent=99),
where special numbers are not allowed in accordance with
http://speleotrove.com/decimal/damodel.html:
"Finite numbers are defined by three integer parameters"
"When a number has one of these special values, its coefficient and exponent
are undefined."
That said, I don't mind if construction continues to work with the
implementation specific value of (0,), so let's do that.
----------
assignee: -> skrah
type: -> behavior
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue15882>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
