Mark Dickinson wrote:
> Python's current support for localization in int and float seems largely 
> accidental, as far as I can tell.

Not at all. The support for non-ASCII numeric characters
in int() and float() is by design - however, I did not look
at things like decimal points, minus/plus signs, etc. at the
time and only included support for numeric values associated
with a number of code points, such as ½ for 1/2.

> But I appreciate the argument that
> despite the current inconsistencies, we shouldn't add extra support 
> without a standard to base it on.
> 
> I'm not sure how relevant TR35 is to this situation;  that seems to be 
> about localization, and I don't really understand why it should be the 
> job of int and float to deal with localization (even though they 
> currently do, to some extent).  I'd even argue for removing support[*] 
> for anything other than ASCII digits from int and float, except that 
> that would likely break existing applications, and annoy people.  Out of 
> curiosity, I asked on #python about this, and found that there are 
> people working with CJK alphabets who find it convenient that int 
> currently accepts fullwidth digits.  I don't know whether there's anyone 
> who cares that int and float currently accept e.g., Devanagari digits.

My suggestion is to wait for the Unicode locale project to collect
locale based information on numeric formatting. I'm sure that some
of this information will be entered back into the Unicode database
in form of code point properties for e.g. decimal points, signs, etc.