[Python-Dev] Decimal conversion to string (original) (raw)

Tim Peters tim_one at email.msn.com
Wed Apr 14 23:13:45 EDT 2004

[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.

More information about the Python-Dev mailing list