prePEP: Decimal data type

[Alex Martelli]

John Roth wrote:
   ...
> Not that hard. It's not at all difficult to find where the actual number
> ends and where the fuzz begins. You can do it visually, and the
> algorithms to do it are quite well known. That's how printing libraries
> handle the issue, after all.

There are several heuristics, but "printing libraries" (???) have nothing
to do with the issue.  I have adopted one such heuristic (Stern-Brocot)
in gmpy at the request of P. Peterson, and there are other popular ones
such as Farey Fractions.  But none is at all perfect.

> You can also special case that with some lightweight compiler
> magic. All that really has to happen is that the lexer has to pass
> the 1.1 to the compiler without converting it to a float first,
> then the parser can apply a special rule when it sees that token
> in the context of decimal(1.1).

So you are proposing that, in this *ONE PLACE* out of ALL the huge
variety in the Python language,

x = 1.1
...
y = decimal(x)

give a DIFFERENT result than

y = decimal(1.1)

???  This is just _not in the cards_.  Python's regularity, uniformity,
and simplicity, are FAR more important than any one "special case" can
possibly be.  Or, as the Zen of Python puts it, "special cases aren't
special enough to break the rules".


> I think someone earlier suggested (in the context of the Money type)
> having the number of digits be an optional arguement to the constructor.
> That is: decimal(1.1, 1) showing one place after the decimal point.

Constructing with some specified precision (not "SHOWING" but actually
constructing) would be fine.  "Places after the decimal point" may or
may not be the ideal way to specify precision, that's a different issue
(if there are any applicable standards, I'd go for those, rather than
make any arbitrary decision in the matter).  But letting the precision
default if left unspecified -- and thus letting construction from floats
just happen -- is a far different decision.  Naive users will always
_believe_ that they're getting "good" precision, if they think at all
about the matter (which unfortunately they may not), unless they _are_
forced to think about the subject by needing to specify precision very
explicitly.  Thus, I think "construction from float with some default
precision" runs a substantial risk of tricking naive users.


Alex