> But in trunk, the value is just used as-is. So when formating a decimal,
> for example, '\xc2\xa0' is just inserted into the result, such as:
format(Decimal('1000'), 'n')
> '1\xc2\xa'
> This doesn't make much sense
I agree with Antoine: it makes sense, and is the correct answer, given
t
> Well, one problem is that it messes up character counts.
Well, I know it does. That's why py3k is inherently better than 2.x's
bytestrings-by-default behaviour. There's a reason we don't try to
backport py3k's unicode goodness to 2.x, and that's it would be terribly
messy to do so while retaini
On Thu, Dec 3, 2009 at 11:33 AM, Antoine Pitrou wrote:
> Eric Smith trueblade.com> writes:
>>
>> But in trunk, the value is just used as-is. So when formating a decimal,
>> for example, '\xc2\xa0' is just inserted into the result, such as:
>> >>> format(Decimal('1000'), 'n')
>> '1\xc2\xa'
>>
Eric Smith trueblade.com> writes:
>
> But in trunk, the value is just used as-is. So when formating a decimal,
> for example, '\xc2\xa0' is just inserted into the result, such as:
> >>> format(Decimal('1000'), 'n')
> '1\xc2\xa'
> This doesn't make much sense,
Why doesn't it make sense? It's
While researching http://bugs.python.org/issue7327, I've come to the
conclusion that trunk handles locales incorrectly in regards to Unicode.
Fixing this would be the first step toward resolving this issue with
float and Decimal locale-aware formatting.
The issue concerns the locale "cs_CZ.UTF-
