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.