Hi all, For those of you not aware, the Julia Programming Language [1] does make extensive use of (mathematical) unicode symbols in its standard library, even document a method of input [2] (hint tab completion). They go even further by recognizing some characters (like \oplus) that parse as operators and have predefined precedences, but no implementations, leaving them available to the user.
Regardless of my personal feeling about that, I have observed that this does not seem to hinder Julia developement. Many developers seem to like it a lot. Though my sampling is heavily biased toward developers with a strong math background. So it might be a case study to actually see how this affect an existing language both technically and community wide. Cheers, -- M [1] : julialang.org [2] : http://docs.julialang.org/en/release-0.5/manual/unicode-input/ [3] : http://docs.julialang.org/en/release-0.5/manual/variables/#allowed-variable-names On Sun, Oct 30, 2016 at 7:02 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 30 October 2016 at 23:39, Paul Moore <p.f.mo...@gmail.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). > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
