Skip Montanaro wrote: > > Please excuse the naive interruption to this discussion. > > I'm a bit removed from this debate, being someone who is generally happy > with ASCII (and who really doesn't understand all the fur that is flying), > however I would imagine that programmers in Moscow writing code to be read > by other Russian programmers would want to enter Cyrillic characters > directly into their module doc strings and not have to insert hex escapes. > Can they safely do that now if they set the encoding variable in site.py > appropriately? If so, what is the need for the proposed directive to set > encodings? Is it an attempt simply to allow different encodings on a > per-module basis? You can only set the default encoding in site.py and this only affects magic conversions from strings to Unicode and back. Unicode literals must currently always use the unicode-escape encoding. The PEP tries to undo with the latter restriction by allowing flexible Python source code encodings on a per-file basis, e.g. Japanese programmer would be able to write source files which use Japanese characters in the Unicode literals which should enhance code readability and user acceptance. > On a related note, can the "Defining Unicode Literal Encodings" PEP be added > to the PEP site/page so those of us who don't save every message that flows > into their inboxes have it to refer to? I will update the pre-PEP according to the findings I've posted under the subject "PEP: Defining Python Source Code Encodings" and then ask Barry to assign a PEP number for the upload. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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