Why not FP for Money?
carribeiro at gmail.com
Sat Sep 25 15:33:47 CEST 2004
On Sat, 25 Sep 2004 08:26:35 GMT, Andrew Dalke <adalke at mindspring.com> wrote:
> Carlos Ribeiro wrote:
> > As a compromise, having the 'd' suffix is better than having no option
> > to write true decimal point literals.
> That's not an effective argument for why a decimal point
> should be made a literal. I use regular expressions much
> more often than decimals -- why shouldn't Python, like
> Perl, support a regular expression literal?
Why not? It may be a good idea for Py3k -- instead of raw strings, why
not regular expressions strings? But as far as decimals are concerned
there's a difference in usage pattern. Numeric literals of any type
can be used in mathematic expressions. Long expressions with class
instantiation style calls are (arguably) less readable than ones
involving only literals; it reads as a function call, not as a literal
instantiation, in that context. Also, a numeric literal has a single
value. What is the 'value' of a RE literal? If it's taken to be the RE
itself (in it's compiled form), I can't see much practical use for
expressions involving literals - even concatenation (ex: re1 + re2)
has nasty side effects in the general case; it's better to concat the
original RE strings and recompile the RE anyway.
> The tension here is between these ideas:
> (1) Special cases aren't special enough to break the rules.
> (2) Simple is better than complex.
> (3) Although practicality beats purity.
(numbers are mine) You've put it perfectly. In my count, decimal
literals win -- (2) + (3) pro, (1) against. But I do use decimals (or
intend to, once it's supported by the database drivers, etc.) -- it
makes (3) true for me and lessens the "special case" clause of (1).
> Why is a decimal point literal special enough to break
> the rule that nearly all objects (except int, string,
> float, complex(!), list, tuple, dict, function, and
> class -- that's quite a few) are created using a
> call-style syntax?
Because (in my opinion) a decimal point literal is in the same general
class as the objects you've mentioned.
Because a decimal point is a number, and numbers are not instantiated
usin call-style syntax.
Because the call-style syntax requires the use of a string as an
argument to avoid practical and phylosophical problems involving the
conversion of binary floats to decimal floats, and the string looks
out of place in numeric expressions.
Because, in the prompt, having a easy way to write numeric literals of
any kind is important to allow seamless interactive use -- be it as
powerful calculator, or to prototype small functions, or to test
> Is it simpler to limit the number of literals, or
> better to simplify making decimal literals?
> I'm against adding new literals. There hasn't been
> one added since complex in ... must have been the
> mid-1990s. I'm not the decision maker here but I'll
> hazard to guess decimal needs to be used more widely
> before making that change.
It's strange, because complex numbers are much more of a special case
than decimals. Decimals have a single value, complex numbers are a
tuple; decimals are orderable; but complex made it to the language. It
was another time, and I don't know how many people rely on Python
complex numbers, but I bet that decimals have the potential to become
more important in the long run.
Consultoria em Projetos
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com
More information about the Python-list