That byte string literals would be in the source encoding at run-time,Īllowing then to output them to a file or render them to the userĪs-is. py with UTF-8.įor Python 2, an important reason for using non-UTF-8 encodings was Yet other editors support associating a default encoding with aįile extension, allowing users to associate. Guess the encoding when reading the file, and UTF-8 is easy to To Python files becomes easier and more portable: On some systems,Įditors will automatically choose UTF-8 when saving text (e.g. When the default encoding is changed to UTF-8, adding non-ASCII text Will) users have to explicitly adjust the encoding which the editor The declarations of PEP 263, many editors still do not (and never Even though some editors (like IDLE and Emacs) support One has to explicitly add an encodingĭeclaration. With PEP 263, using arbitrary non-ASCII characters in a Python file is Gives an error if non-ASCII characters are encountered and no source This transition ended with Python 2.5, which With Python 2.0 and 2.1, files were interpreted as Latin-1 for a If no sourceĮncoding was given, the default should be ASCII. Introduced a syntax for declaring the source encoding. PEP 263 identified the problem that you can use only those UnicodeĬharacters in a Unicode literal which are also in Latin-1, and

Least for files containing non-ASCII characters in Unicode literals. To code points, this algorithm effectively fixed a source encoding, at

Were still copied literally from the source file, but widened on aĬharacter-by-character basis. For Unicode string literals, the characters In Python 2.0, the source encoding changed to Latin-1 as a side effect The contents of a string literal was copied literally from the file Letters for keywords, identifiers, punctuation, line breaks, etc). The sourceĮncoding was only relevant for the lexis itself (bytes representing

Source encoding had to be a superset of the system’s basic executionĬharacter set (i.e. In Python 1, the source encoding was unspecified, except that the Support for alternative source encodings ( PEP 263) continues toĮxist an explicit encoding declaration takes precedence over the

This PEP proposes to change the default source encoding from ASCII to PEP 3120 – Using UTF-8 as the default source encoding PEP 3120 Title Using UTF-8 as the default source encoding Author Martin von Löwis Status Final Type Standards Track Created 1 Python-Version 3.0 Post-History PEP 3120 – Using UTF-8 as the default source encoding.PEP 3120 – Using UTF-8 as the default source encoding | Python Enhancement Proposals

Default text encoding