Author mark.dickinson
Recipients eric.smith, ezio.melotti, ggenellina, lemburg, loewis, mark.dickinson, pitrou
Date 2009-08-06.12:14:49
SpamBayes Score 6.56142e-14
Marked as misclassified No
Message-id <>
Python's current support for localization in int and float seems largely 
accidental, as far as I can tell.  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.

I guess I'm +0.2 for preserving the status quo, for now.

([*] I'm aware that I'm being a bit inconsistent here, since I was 
recently arguing that the Decimal type should accept non-European 
decimal digits partly based on the fact that int and float do.  But in 
the case of Decimal there's an underlying standard that recommends 
acceptance of these digits, and compliance with that standard has 
generally taken precedence over consistency with Python's other numeric 
Date User Action Args
2009-08-06 12:14:53mark.dickinsonsetrecipients: + mark.dickinson, lemburg, loewis, ggenellina, pitrou, eric.smith, ezio.melotti
2009-08-06 12:14:52mark.dickinsonsetmessageid: <>
2009-08-06 12:14:51mark.dickinsonlinkissue6632 messages
2009-08-06 12:14:49mark.dickinsoncreate