homepage

Ezio Melotti asked (on #python-dev) why the Decimal constructor doesn't 
accept decimal digits other than 0-9. As far as I can tell there's no 
good reason for it not to. Moreover, the standard on which the decimal 
module is based says[1]:
"""It is recommended that implementations also provide additional number 
formatting routines (including some which are locale-dependent), and if 
available should accept non-European decimal digits in strings."""
All other builtin or standard library numeric types already accept such 
digits:
Python 3.2a0 (py3k:74247, Jul 29 2009, 09:28:12) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from fractions import Fraction
>>> from decimal import Decimal
>>> x = '\uff11\uff10\uff15\uff18\uff15'
>>> x
'10585'
>>> int(x)
10585
>>> float(x)
10585.0
>>> complex(x)
(10585+0j)
>>> Fraction(x)
Fraction(10585, 1)
>>> Decimal(x)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 548, in 
__new__
 "Invalid literal for Decimal: %r" % value)
 File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 3816, in 
_raise_error
 raise error(explanation)
decimal.InvalidOperation: Invalid literal for Decimal: '10585'
I propose adding support for this in Python 3.2 and (possibly) 2.7. The 
change would be for input only: no record of the original form of the 
digits would be kept by the Decimal object itself, so that e.g.,
str(Decimal('10585')) would still be '10585'.
[1] See http://speleotrove.com/decimal/daconvs.html 

Here's a patch

+1
The standard recommends it, and the other numeric types support it, so
Decimal should as well.

Since you're calling int() on the result, can't this code:
self._int = str(int((intpart+fracpart).lstrip('0') or '0'))
just be:
self._int = str(int(intpart+fracpart))
?
And here, you already know diag is not None, so do you need the "or '0'"
part?
self._int = str(int(diag or '0')).lstrip('0')
And, in both calls to .lstrip('0'), what happens if you have a
non-European leading '0', like '\uff10'?
Otherwise, the patch looks good to me.

+1
Also, I would like to see this backported. We've long promised that any
variance with the spec will be treated as a bugfix. The change won't
break any existing code.

Thanks for the feedback; I've added 2.6, 2.7, 3.1 to the
versions and will backport.
[Eric]
> Since you're calling int() on the result, can't this code:
> self._int = str(int((intpart+fracpart).lstrip('0') or '0'))
> just be:
> self._int = str(int(intpart+fracpart))
> ?
Yes! Thank you. I'm not sure what (if anything) I was thinking here.
The str(int(...)) hack is quite an ugly way to normalize a string; it 
also has the drawback of taking time quadratic in the length of the 
input. In its defence: (a) I can't think of anything better; (b) this 
change seems to have no noticeable effect on the time to run the test-
suite, and (c) since all the arithmetic operations use string <-> int 
conversions anyway the quadratic time behaviour doesn't really make 
things any worse than they already are.
> And here, you already know diag is not None, so do you need the "or 
'0'"
> part?
> self._int = str(int(diag or '0')).lstrip('0')
I think *something* like this is needed, since diag can legitimately be 
the empty string. It might be clearer as a proper if block, though: 
'if diag: ... else: ...'.

I like the str(int(...)) approach because it guarantees handling that
is consistent with other types.

Committed to py3k in r74279, release31-maint in r74280. Leaving open for 
backport to 2.x.

Backported to trunk and release26-maint in r74281 and r74282.