translating foreign data

[Steven D'Aprano]

On Fri, 22 Jun 2018 20:06:35 +0100, Ben Bacarisse wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
> 
>> On Fri, 22 Jun 2018 11:14:59 +0100, Ben Bacarisse wrote:
>>
>>>>> The code page remark is curious.  Will some "code pages" have digits
>>>>> that are not ASCII digits?
>>>>
>>>> Good question.  I have no idea.
>>> 
>>> It's much more of an open question than I thought.
>>
>> Nah, Python already solves that for you:
> 
> My understanding was that the OP does not (reliably) know the encoding,
> though that was a guess based on a turn of phrase.

I took it the other way: that Ethan *does* know the encoding, and his 
problem is that knowing the encoding and/or locale is not enough to 
recognise whether to use a period or comma as the decimal separator.

Which it isn't.

If he doesn't know the encoding, he has bigger problems than just 
converting strings into floats. Without knowing the encoding, he cannot 
even reliably detect non-ASCII digits at all.


> Another guess is that the OP does not have Unicode data.  The term "code
> page" hints at an 8-bit encoding or at least a pre-Unicode one.

Assuming he is using Python 3, or using Python 2 sensibly, once he has 
specified the encoding and read the data from the file, he has Unicode.

Unicode is a superset of (ideally) all code pages. Once you have decoded 
the data using the appropriate code page, you have a Unicode string, and 
Python doesn't care where it came from.

The point is, once Ethan can get the intended characters out of the file 
into Python, it doesn't matter what code page they came from. They're now 
full-fledged Unicode characters, and Python's float() and int() functions 
can easily deal with non-ASCII digits. So long as he has digits in the 
first place, float() and int() will deal with them correctly.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson