[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4