On 30 October 2016 at 23:39, Paul Moore email@example.com wrote:
It's certainly not difficult, in principle. I have (had, I lost it in an upgrade recently...) a little AutoHotkey program that interpreted Vim-style digraphs in any application that needed them. But my point was that we don't want to require people to write such custom utilities, just to be able to write Python code. Or is the feeling that it's acceptable to require that?
Getting folks used to the idea that they need to use the correct kinds of quotes is already challenging :)
However, the main issue is the one I mentioned in PEP 531 regarding the "THERE EXISTS" symbol: Python and other programming languages re-use "+", "-", "=" etc because a lot of folks are already familiar with them from learning basic arithmetic. Other symbols are used in Python because they were inherited from C, or were relatively straightforward puns on such previously inherited symbols.
What this means is that there aren't likely to be many practical gains in using the "right" symbol for something, even when it's already defined in Unicode, as we expect the number of people learning that symbology *before* learning Python to be dramatically smaller than the proportion learning Python first and the formal mathematical symbols later (if they learn them at all).
This means that instead of placing more stringent requirements on editing environments for Python source code in order to use non-ASCII input symbols, we're still far more likely to look to define a suitable keyword, or assign a relatively arbitrary meaning to an ASCII punctuation symbol (and that's assuming we accept that a proposal will see sufficient use to be worthy of new syntax in the first place, which is far from being a given).