homepage

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.