On Thu, May 21, 2020 at 04:04:20PM +0200, Thierry Parmentelat wrote: > for all the rest, I am sorry, all the arguments about people having > trouble inputing those characters are not relevant, it’s not as if > using unicode characters was mandatory
If we still have to come up with a good looking, unambiguous per ASCII digraph or trigraph symbol, then what does the Unicode symbol grant us? The moment we say "why bother with the ASCII digraph, everyone can use the Unicode symbol?" then we are proposing that it be mandatory. Even if it is not mandatory, people will want to use the same symbol throughout a project. Once somebody allows → in a module, they're probably going to require → and reject patches using -> Now of course people can *work around this* by copying and pasting, symbol palettes, etc but it does add to the friction of using Python. If the benefit isn't greater than the amount of friction, the overall experience is worse. Allowing Unicode symbols expands the range of operators and special symbols we can use, and potentially makes it easier to add new language features. But if we have ASCII fallbacks for every one of those, then it doesn't add any extra power or functionality to the language, it just adds complexity for minimal benefit. > arguments about some people not seeing such code properly are of > course much more valid but you seem to forget that using unicode > characters is already possible in strings, and identifiers even so > somebody else opened that box already … And if IDLE can’t do it, it’s > a problem already Indeed, this is true, but neither identifiers nor strings carry syntactic meaning. We don't has to ask what the identifier straß means to understand the code, at worst we could treat it as an obfuscated name like xyz. Likewise for string constants. Mandatory or not, giving syntactic meaning to Unicode symbols (as opposed to merely allowing them in indentifiers and strings) will lead to a massive increase in community questions: "What's the meaning of that curly less than sign ⊰ in Python?" or more likely: "What's with all the small boxes '' in Python code?" (assuming they even display at all, in my mail client the above symbol displays as a space; they could easily also display as �). So unless you're volunteering to personally seek out and answer all those questions, this can only increase the amount of community support needed for not very much benefit at all. We have had non-ASCII identifiers for, oh, 15 or 20 years now, but still the vast bulk of identifiers use nothing but ASCII, even when not written in English. At least for projects which have much visibility in the public, English-speaking internet :-) (I expect that people and companies use a lot more non-ASCII in their private code. And there is an interesting little project called ChinesePython that translates the language into Chinese, but I don't know how successful it is or if it is even still maintained.) So the cost of allowing non-ASCII identifers is much lower than the cost of non-ASCII symbols; even if the benefit is low, it can still be a win for non-ASCII identifiers and strings, while the cost:benefit ratio end up negative for non-ASCII symbols. > I am convinced this will happen, one day or another, with or without > Python, only question is when, not if *shrug* If you are serious about persuing this, you could start by doing a survey of what other languages allow non-ASCII symbols, and report on their experience and popularity. You might also check out Coconut, which is superset of Python that compiles down to Python. Another option might be to provide a pre-processor that translates (say) → into -> for example. We might have .pyu files (u for unicode) translate into .py files before being compiled or run. A good practical project for someone seriously interested in advancing this idea would be a translator that goes in both directions, from pure ASCII to non-ASCII. (Remember that string literals, docstrings and comments shouldn't be touched.) -- Steven _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HQLA3UW5LFSOLT6JZXGSPPHKVPZQ3J4Q/ Code of Conduct: http://python.org/psf/codeofconduct/
