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
'１０５８５'
>>> 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: '１０５８５'

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('１０５８５')) 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.