There is a representation for decimal literals that nicely avoids the problem of remembering that 0d is decimal and 0m is meters etc.:
>>> import decimal
>>> decimal.Decimal(3)
Decimal("3")
>>> Decimal("3")
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'Decimal' is not defined
The error points out that I really need to do both:
>>> import decimal
>>> from decimal import Decimal.
and I'd prefer the single import do both. Note that this anomaly of repr is not limited to decimal as I think this is a bit worse:
>>> float('nan')
nan
>>> float('inf')
inf
--- Bruce
On Fri, Dec 5, 2008 at 10:53 AM, Jim Jewett
<jimjjewett@gmail.com> wrote:
On Thu, Dec 4, 2008 at 4:45 AM, Cesare Di Mauro
> But at least it will be more usable to have a
> short-hand for decimal declaration:
In isolation, a decimal literal sounds nice.
But it may not be used often enough to justify the extra mental complexity.
What should the following mean?
>>> a = 123X
It isn't obvious, which means that either it gets used all the time
(decimal won't) or people will have to look it up -- or just guess,
and sometimes get it wrong.
> a = 1234.567d
To someone who hasn't programmed much with decimal floating point,
what does the "d" mean?
Could it indicate "use double-precision"?
Could it just mean that the written representation is "decimal" as
opposed to "octal" or "hexadecimal", but that the internal form is
still binary?
> a = 1234.567d
> is simpler than:
[reworded to be even shorter per use]
>>> from decimal import Decimal as d
>>> a = d('1234.5678')
but if you really have enough Decimal literals for the difference to
matter, you could always write your own helper function.
>>> # pretend to be using the European decimal point
>>> a = d(1234,5678)
>>> # maps easily to the tuple-format constructor
>>> a = d(12345678, -4)
My own hunch is that until Decimal is used enough that people start
putting this sort of constructor into their personal libraries, it
probably doesn't need a literal.
-jJ