> Please note that > u'<whatever-in-ascii>' is interpreted just literally and we > cannot put Japanese characters in string literals legally for > now anyway. Would you like to be able to? The PEP will allow this -- that's its whole point! > > I think I can propose a compromise though: there may be two default > > encodings, one used for Python source code, and one for data. > > Normally, a single default encoding is used for both cases, but it is > > possible to specify two different defaults, and then persons who like > > UTF-16 can set ASCII as the default source encoding but UTF-16 as the > > default data encoding. > > It sounds very nice. I understand that the default data > encoding will be applied to what from file objects. It must be > the only(?) satisfying solution if the default source encoding > is to be set in site.py. > # Or else we should give up the default encoding for data... I would strongly encourage the latter. Are you really sure that there isn't a better way to avoid having to type the encoding name all the time? E.g. define your own helper functions? > I'm sorry for the ambiguity. > I proposed ASCII as the _minimum_ request. I'd _hope_ UTF-8. I will ignore the rest of your message, which is just repeating age-old arguments why we should use UTF-8. We have considered this carefully in the past, and rejected the idea. I see nothing new in your argument. And yes, using ASCII is unfair to all non-English speakers. But Python uses English keywords anyway; I don't think we should strive for total cultural relativism, and it's certainly not a fight I feel the desire to fight for now. --Guido van Rossum (home page: http://www.python.org/~guido/)
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