Steven Bethard wrote: > On Wed, Jan 28, 2009 at 10:29 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote: >> Notice that the determination of the specific encoding used is fairly >> elaborate: >> - if IO is to a terminal, Python tries to determine the encoding of >> the terminal. This is mostly relevant for Windows (which uses, >> by default, the "OEM code page" in the terminal). >> - if IO is to a file, Python tries to guess the "common" encoding >> for the system. On Unix, it queries the locale, and falls back >> to "ascii" if no locale is set. On Windows, it uses the "ANSI >> code page". On OSX, it uses the "system encoding". >> - if IO is binary, (clearly) no encoding is used. Network IO is >> always binary. >> - for file names, yet different algorithms apply. On Windows, it >> uses the Unicode API, so no need for an encoding. On Unix, it >> (again) uses the locale encoding. On OSX, it uses UTF-8 >> (just to be clear: this applies to the first argument of open(), >> not to the resulting file object) > > This a very helpful explanation. Is it in the docs somewhere, or if it > isn't, could it be? Here is the current entry on encodings in the Lib ref, built-in types, file objects. file.encoding The encoding that this file uses. When strings are written to a file, they will be converted to byte strings using this encoding. In addition, when the file is connected to a terminal, the attribute gives the encoding that the terminal is likely to use (that information might be incorrect if the user has misconfigured the terminal). The attribute is read-only and may not be present on all file-like objects. It may also be None, in which case the file uses the system default encoding for converting strings.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4