[Python-Dev] Decimal conversion to string

[Tim Peters]

[Ping]
>> Could we please have repr(d) use the string in the constructor
>> rather than the tuple form?  That would be much easier to read.

[Batista, Facundo]
> To *me* is more natural the tuples. But that's only because that's what
> the internal objects are.

The standard's to-scientific-string operation produces a human-readable
string with 1-to-1 correspondence between strings and internal
representations.  So it's suitable for both human use and as repr() output;
it's also suitable for str() output.  Tuples are (IMO) *only* interesting to
implementers.  That's OK -- give 'em an as_tuple() method instead.  The
repr() and str() forms really should be readable by end users.

> An intermediate solution can be something like:
>
> >>> Decimal('12345')
> Decimal(0, 12345, 0)
>
> a tuple of three values: sign, coefficient, and exponent. The three of
> them as integers.}

Then we've got quadratic-time requirements for eval(repr(Decimal)), because
the coeffecient takes time quadratic in the number of decimal digits to
convert to a Python integer, and then there's *another* quadratic-time
operation needed to break the Python integer back into its digits.  The
string and tuple forms are linear-time, so don't suffer this ugliness.  The
to-scientific-string form is also readable by end-users with no education on
the topic.

> Anyway, if you want to change the repr() behaviour, you should push it
> hard to the list. I'm -0 on it.

+1 here, for the reasons above.

Also +0 on adding an .as_tuple() method.  I can't be stronger than +0 on
that, because tuples of single decimal digits reveal *too* much about the
current implementation.  For example, a speedier implementation could use
base 100 or base 10000 (or ...) internally, and then its idea of a natural
tuple representation would be correspondingly different.  The standard
already goes to great pains to define a canonical and readable string
representation, so let's use it.