[Guido van Rossum] > To the contrary, I wish GNU readline didn't call setlocale(). So, that's why it works interactively, and not in batch, then! > and tying such a proposal to this PEP is definitely the wrong thing. Expected and understood. I merely hope that this PEP's "concept" will not later be quoted as rigid. Going back from Unicode through ASCII may be today's way for implementing PEP 263, but not necessarily the only one. > Allowing non-ASCII identifiers may eventually happen, but there are > lots of reasons why it's a bad idea (such as source code portability), If Unicode letters get eventually accepted in Python identifiers, I do not much see what portability problems it would create. I mean, not more than with generators, or any other Python feature. It's forward compatible. Unless you mean that by encouraging non-English writings, _this_ creates a threat to portability, where English is the planetary computer language for exchanges. The point is that many Python programs, contrarily to the Python distribution itself, are not aiming the planet, and for some communities or teams, would be more useful and comfortable if not English. Each thing in its proper time, of course. Just let's keep the doors opened. -- François Pinard http://www.iro.umontreal.ca/~pinard
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