math.π instead of math.pi

That is already possible, just not done in the standard library, no? Your point still stands, but it's rather different to your other examples, which are actual changes to syntax. With regards to the actual proposal, I quite like the idea of being able to use them, but I don't think it's worth portability issues - style guides would just end up forbidding it anyway. They're also hard to type, and of course,

There should be one-- and preferably only one --obvious way to do it.

On Sun, 17 May 2020 at 13:32, Alex Hall <alex.mojaki@gmail.com> wrote:

On Sun, May 17, 2020 at 2:24 PM Thierry Parmentelat < thierry.parmentelat@inria.fr> wrote:

...

well it’s all in the title

the specific character that I am referring to is this one

In [1]: print("\u2192”) →

https://unicode-table.com/en/2192/

——

just curious about how people would feel about taking better advantage of non-ascii characters when that seems to make sense

fyi here’s how both options appear in a markdown-based website

I'm not a fan of the idea, just in case the code ends up being copied somewhere it can't be rendered properly.

If we consider the arrow, what about ≤ instead of <=, ≥ instead of >=, ≠ instead of !=, × instead of `*`, and math.π instead of math.pi? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/EKQ4WJ... Code of Conduct: http://python.org/psf/codeofconduct/

Before this goes too a big shaky bikeshed over almost nothing, let me point out that if you're looking to improve something in type annotations, I would suggest to look for true ugliness there. Something like Callable[[Dict[str, int], Sequence[Foo]], Dict[PrimaryKey, List[int]]]. That's rather unreadable.

totally agree on the awkwardness :-)

Actually, let me just quote https://docs.python.org/3/library/typing.html#typing.Callable

...

Callable type; Callable[[int], str] is a function of (int) -> str.

Lolwhat? If it's a function of "(int) -> str", then it should be written just about like that. With https://www.python.org/dev/peps/pep-0563/ , a lot of things which weren't previously possible, are now possible. Somebody should start thinking how to take advantage of that, up to allowing "(int) -> str”.

would be nice too - although this is orthogonal to my initial proposal, right ?

Which is apparently not possible currently, as while "evaluation" is postponed, it still should parse eagerly as Python syntax. But even {(int): str} is a better type annotation for a function than Callable[[int], str].

well, {(int): str} already means something; are you suggesting that an expression like this could have different meanings whether it’s in an annotation or not ? that sounds scary ...

And if we e.g. talk about making "->" a special operator which would allow it to appear in other contexts than function definition, "(int) -> str" (and other interesting annotation syntaxes) would be possible.

again, that’s be quite cool for typing function parameters :)

On 2020-05-18 02:25, Greg Ewing wrote:

On 18/05/20 1:59 am, Paul Sokolovsky wrote:

...

But even {(int): str} is a better type annotation for a function than Callable[[int], str].

I don't agree -- it looks more like some kind of dict type, and would be better reserved for that purpose.

...

And if we e.g. talk about making "->" a special operator which would allow it to appear in other contexts

Or maybe we could leverage the new walrus operator and write

str := (int)

It would be closer to the existing annotation if we could write: [int] -> str

On Tue, May 19, 2020 at 11:31 AM Brett Cannon <brett@python.org> wrote:

I'm going to ask that people please try to keep this thread on-topic to the question of using Unicode characters directly for things that we currently use two ASCII characters to represent.

Indeed -- and also: please refer to earlier conversations on this list and elsewhere -- this is NOT a new idea! I'd suggest also that the question at hand be more global: Should Python be extended to allow non-ascii characters in syntax? Rather than one or two specific ones. ON a related note, another way to get "Nicer" multi-character operatores is lignatures. Jet BRains has put out a font with a pretty full set: https://www.jetbrains.com/lp/mono/#ligatures (you can use that font with most Editors / IDEs -- works great with Sublime, for instance) That way, it's still two ascii characters, but it looks like one nifty symbol in your editor. Maybe no need to complicate Python? ;-) -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat <thierry.parmentelat@inria.fr> wrote:

I also reckon it is still cumbersome to simply enter Unicode characters from a keyboard sometimes; I guess if the big players were located in other countries that would maybe be different But that will change over time, no matter the speed, some day that will be for granted So again maybe 2020 is the right time to break that barrier ?

The Dvorak keyboard was invented nearly a hundred years ago. How's it looking as a viable alternative? If you think that a keyboard with fancy arrows on it will take off any quicker, you're extremely hopeful. MUCH more practical will be to use vim conceal etc, leave your source code unchanged, and just change the way it looks to you. There are similar features available in a number of editors. ChrisA

On Thu, May 21, 2020 at 1:48 AM Ethan Furman <ethan@stoneleaf.us> wrote:

On 05/20/2020 12:44 AM, Chris Angelico wrote:

...

On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat wrote:

...

...

I also reckon it is still cumbersome to simply enter Unicode characters from a keyboard sometimes; I guess if the big players were located in other countries that would maybe be different.But that will change over time, no matter the speed, some day that will be for granted.So again maybe 2020 is the right time to break that barrier ?

The Dvorak keyboard was invented nearly a hundred years ago. How's it looking as a viable alternative?

Well, 25 years ago I had to write my own Dvorak device driver for use with MS-DOS, now it's included in at least Windows and Linux (a Dvorak mapping, not my device driver).

So much more viable. :)

...

If you think that a keyboard with fancy arrows on it will take off any quicker, you're extremely hopeful.

I wouldn't be surprised if it did, although a standard set of keyboard shortcuts is more likely.

I'm pretty doubtful. Keyboards seem to be LOSING keys, not gaining them. Which is a trend that I deplore (where are my F1-F12 keys?? and I doubt I'll ever see F13-F16), but I still cling to the hope that not ALL keyboards are going that way. ChrisA

On 2020-05-20 00:44, Chris Angelico wrote:

If you think that a keyboard with fancy arrows on it will take off any quicker, you're extremely hopeful.

While I'm not sure how useful this is in the long run, the oft mentioned drawback of "hard to type/view" Unicode chars isn't as insurmountable as some think: - Word processors have had a palette to insert symbols for decades. - Editors have had "snippets" for perhaps almost as long. - Code formatters such as "go fmt", yapf, black, etc could update them. - All maintained OSs support a great majority of Unicode, with font support. - AltGr and Compose keys are available. I've been using Unicode everywhere for about a decade—it's time to retire the argument that input is still hard or rare. Dedicated keys are not really necessary. -Mike

On 20 May 2020, at 23:56, Steven D'Aprano <steve@pearwood.info> wrote:

...

I've been using Unicode everywhere for about a decade—it's time to retire the argument that input is still hard or rare.

I can sincerely say that I am very happy that your experience is so good, but I'm also exceedingly jealous of it. I don't think your experience scales to the majority of people.

I guess we’re getting to the gist of it I was not proposing that everybody MUST enter → I was suggesting that some people MAY want to do that so their code looks prettier in contexts where no additional intelligence is available to embellish things Do we want to get stuck in the 20th century just because everything is not yet perfect in a non-purely ASCII world ?

On 2020-05-20 14:56, Steven D'Aprano wrote:

Not everyone is programming in a GUI environment all the time

Well, I gave a number of examples to show there are many ways to do it. Not every example will work well for everyone. The best that works for your platform and tools should be chosen. There are numerous others I didn't bother to mention.

...

- Code formatters such as "go fmt", yapf, black, etc could update them.

I think this is the choice with the least effort required, a code formatter. For example, a tip was given to me that you can save keystrokes writing Python by using single-quotes exclusively (which I do) then let black change them to double later. I still come across

monospaced fonts where certain symbols have annoying "off by one pixel" display bugs, or are missing the exact symbol you need.

I use "Source code pro" often and Symbola occasionally and they work well. Full math notation is problematic and likely farther than anyone is proposing. I do use box-drawing occasionally and don't have any alignment problems with them even cross-platform.

I can sincerely say that I am very happy that your experience is so good, but I'm also exceedingly jealous of it. I don't think your experience scales to the majority of people.

It's true that I did take a few moments to configure things to make it easier for me. Once done however, easy. But, the majority is now using emoji everywhere, in defiance of curmudgeons. I've never heard anyone complain it's "too hard." -Mike

On 21 May 2020, at 14:48, Joao S. O. Bueno <jsbueno@python.org.br> wrote:

(I had a coleague once which did set a special VIM config to display "!=" as "[can't type, math 'different' sign from here]" and even that was mostly a toy than anything really useful.

I guess that is my point exactly: the main reason why this person has been unable to make anything useful out of that otherwise perfectly sound idea is that it is not allowed in the language, so people need to mess with solutions on the outside sphere - editors, IDE’s, documentation post-processing - that essentially have no chance to be sustainable, and/as it causes extra burden for everybody We should allow code to be natively pretty, and not rely on other tools to do the prettifying job - or not

On 21 May 2020, at 15:19, Joao S. O. Bueno <jsbueno@python.org.br> wrote:

That is, if you answered the question about which right arrow to use, asked above)

that’s an easy one, see the OP In [1]: print("\u2192”) → 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 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 I am convinced this will happen, one day or another, with or without Python, only question is when, not if

On 21 May 2020, at 23:03, David Mertz <mertz@gnosis.cx> wrote:

You are SERIOUSLY suggesting that typing 'Ctrl-Shift-U 2 1 9 2 <enter>' is easier for me than typing '->' as I do now!?

that’s not how I’d do it; and I dont think I said or suggested anything to that effect

And it remains easier if I use a different computer where I have to figure out or remember some different way of getting the Unicode code point into the editor?

The goal of this being to wind up with source code that will render gray boxes for unknown character if I don't have the right font or the right display context?

Even if *I* don't start using that special character (or others), I wind up having to edit and view code that other people have written, which means I need to deal with a tool stack to handle things that are hard to enter on most keyboards.

this thread seems to be obsessing on entering with the keyboard; that is not my point at all

As is... my editor looks like this. I don't type all those special things, except once in a configuration file. But the "prettification" is handled transparently when I type some ASCII sequences.

that’s nice ! it’s a real shame though, and a bit of a waste honestly, that everybody needs to cook their own brew of an editor to get there and primarily all I’m trying to say is that, one day, this will be a legal piece of code, so that we can share and enjoy exactly like this instead of in poor work-it-out-yourself ascii

On 5/21/2020 5:51 PM, Thierry Parmentelat wrote:

...

Python-arrow.png

that’s nice ! it’s a real shame though, and a bit of a waste honestly, that everybody needs to cook their own brew of an editor to get there and primarily all I’m trying to say is that, one day, this will be a legal piece of code, so that we can share and enjoy exactly like this instead of in poor work-it-out-yourself ascii Could you please explain to me how an entry method for → makes for better programmer productivity than what you call "work-it-out-yourself ascii"?  I want a specific scenario, like "1 less key press" or whatever, not some kind of "we all use emojis" hand-waving.  How would this make me a more productive programmer?  Given that -> is never going to disappear from Python anyway, how will this make the code easier to understand?

I believe I speak for a significant majority of professional programmers when I say that eye-candy like this adds no value to the language for me.  It gives me no new capabilities, I don't see it making me more productive, and we have syntax that works quite well already. What if I want to use a font in my editor that doesn't support →?  Does that mean that I won't be able to edit some random bit of code I download? --Edwin

As is... my editor looks like this. I don't type all those special things, except once in a configuration file. But the "prettification" is handled transparently when I type some ASCII sequences. [image: Python-arrow.png]

that’s nice ! it’s a real shame though, and a bit of a waste honestly, that everybody needs to cook their own brew of an editor to get there and primarily all I’m trying to say is that, one day, this will be a legal piece of code, so that we can share and enjoy exactly like this instead of in poor work-it-out-yourself ascii

The first screenshot (of completely pointless code I just typed to use a few symbols or sequences) used vim conceal plugin; also my particular configuration of what to substitute visually on screen. That approach lets entire patterns get replaced by... whatever you want. E.g. I replace `set()` with the empty-set symbol, but no one else is required to by the plugin if they don't want to (or the script Z/R for int/float, likewise). For comparison, I changed my system text editor to use JetBrains Mono Medium. The editor is called "Text Editor" on my system, but it's a rebranded gEdit, which is a pretty reasonable code editor. Someone else in the thread pointed to that font which uses ligatures to make composed characters. So it's not a substitution but simply another way of drawing some letter pairs. The result is in the attached screenshot. This approach is somewhat less flexible in that it gets exactly those ligatures that JetBrains decides you want. In concept, there is no reason this couldn't create a 'float' ligature that renders as a script R, for example. But that is not a combo JetBrains decided to use. The main point of this, is that the code is still just plain ASCII, it just happens to look "fancier." It requires no plugins, and it does not require a JetBrains IDE or editor. I haven't tried every editor, but I believe that most or all that use GUI fonts will work fine. Not sure about ligatures and Linux terminal, someone can try it. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

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

Executive summary: I'd like to make three points. 1. Accessibility matters, and I think this change would be inaccessible to users of screen readers. 2. Yes, a variety of tools imposes a burden, but also confers benefits. 3. There's no such thing as "pretty source code." There are only tools that display source code beautifully. Down and dirty details: The first is new to this discussion: Let's not make life more annoying for the accessibility developers and the people who *need* accessibility accommodations. Not all visual puns are audible puns. "→" looks like "->", but "Unicode U+2192 RIGHTWARDS ARROW" sounds nothing like "HYPHEN GREATER-THAN". (I'm guessing at the pronunciation, I don't use a screen reader myself. OK, probably the reader just says "RIGHTWARDS ARROW" or even "RIGHTARROW", but it's still not close to the same.) At the very least, we should do a case-by-case check when we want to pun this way, and also ask an accessibility expert (better three) about whether screen readers make this connection, and if not, whether their users would be able to. Second, about Tower-of-Babelonian tool proliferation: Thierry Parmentelat writes:

people need to mess with solutions on the outside sphere - editors, IDE’s, documentation post-processing - that essentially have no chance to be sustainable, and/as it causes extra burden for everybody

This situation that has no chance to be sustainable obviously *is* sustainable. It's been this way for as long as I've been using computers (daily use for work or study since 1979). I very much doubt it is going to change, ever, because tools are personal. Yes, it causes a certain amount of burden for everybody, but it also provides great benefits for everybody, or network externalities would impel us to accept a common set of tools.

We should allow code to be natively pretty, and not rely on other tools to do the prettifying job - or not

There's no such thing as code being "natively pretty". Code (source code) is a sequence of bits grouped into bytes grouped into characters grouped into statements grouped into a file. I can't see the pits on a BD or the microwaves in a wireless connection, and I doubt you can. There are software tools doing a prettifying job every time source code is displayed, printed, or read out loud, and a mass audience language like Python needs to adapt to the tools of the mass audience. Yes, we humans can help relatively "dumb" tools do a better job of displaying pretty code (for example, "significant whitespace"), but it's the quality of tool that matters most. Fred Brooks had a good essay on "sharp tools", slightly off-point, in *The Mythical Man-Month*. (I'm pretty sure of the citation but unfortunately my copies of MMM are all at school for access by my students. :-) He advocated having a tool-building specialist on his "surgical team" of (proprietary) developers, but in the open source world, we all publish our tools, which is both the glory and the disaster of something like Emacs. There are also habits that won't change -- even if *you* habitually use one of the many right arrows in Unicode instead of "->", most of us will continue to touch-type "->", and you're going to have to read it. And code is eternal: 20 years from now, somebody's going to be upset about some misfeature in the stdlib, and they're going to have to read it. (Well, maybe not "->", depends on whether they need to look at the stub files, which is a "probably not", stub files are more useful to the Python compiler than to humans most of the time.) If you want all your Python code to use non-ASCII characters in the syntax whether you wrote it or not, *your tools will have to do it for you*. Steve

On Thursday, May 21, 2020, at 8:48, Joao S. O. Bueno wrote:

On Wed, 20 May 2020 at 17:17, Mike Miller <python-ideas@mgmiller.net> wrote:

...

On 2020-05-20 00:44, Chris Angelico wrote:

...

If you think that a keyboard with fancy arrows on it will take off any quicker, you're extremely hopeful.

While I'm not sure how useful this is in the long run, the oft mentioned drawback of "hard to type/view" Unicode chars isn't as insurmountable as some think:

- Word processors have had a palette to insert symbols for decades. - Editors have had "snippets" for perhaps almost as long. - Code formatters such as "go fmt", yapf, black, etc could update them. - All maintained OSs support a great majority of Unicode, with font support. - AltGr and Compose keys are available.

I've been using Unicode everywhere for about a decade—it's time to retire the argument that input is still hard or rare. Dedicated keys are not really necessary.

Input _is_ hard or rare. Deal with it.

[...]

It seems that the only sane thing to do is to use a baseline of well established symbols on source code [...]

According to https://en.wikipedia.org/wiki/Digraphs_and_trigraphs, Python is already on thin ice by using the full set of ASCII characters. I wonder how many non-native English speakers have given up on Python because of that. I'm old enough to remember terminals that didn't support lower case letters, let alone "curly braces," and to have used dozens of different keybpards with all sorts of "common" symbols (e.g., [, {, /, \, <) in all sorts of different places. I had a customer who was old enough to use upper case letter O for zero and lower case letter l for 1 because she was old enough to have learned to type before typewriters had number keys; that made a real mess of sorting street addresses. But I digress. Sort of. Yes, some characters are harder to enter for some people at some times. We're all different, and so are our computing tools. Imagine that. When I studied Koine Greek in school (c. 2003 or 2004), I learned what I had to to type up my homework. Was I fast? No, not really. Was I fast enough? Yep. I'm not for full blown, use every Unicode character we can, but I'm not against using characters outside the ISO 646 invariant character set, either. Using π or ϖ as an alias for math.pi? Not too bad. Matched pairs of left/right quotation marks? Maybe, but not without a lot more thought. Different right arrows for different operations? That's asking for trouble. -- “Atoms are not things.” – Werner Heisenberg Dan Sommers, http://www.tombstonezero.net/dan

On Friday, May 22, 2020, at 8:28, Steven D'Aprano wrote:

On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote:

...

I had a customer who was old enough to use upper case letter O for zero and lower case letter l for 1 because she was old enough to have learned to type before typewriters had number keys; that made a real mess of sorting street addresses.

https://historythings.com/life-changing-invention-typewriters/

I can see 0, 2, 3, 4, 5, and 6 clearly. I can't see a 1, although it appears that the key between the 0 and the Q is missing its label.

https://historythings.com/wp-content/uploads/2016/07/9999006136-l.jpg

The photo isn't clear enough to see the keys, but there are 44 of them. Since the Sholdes typewriter didn't have lowercase letters, it's hard to imagine what the remaining keys after the uppercase letters and punctuation marks were if they weren't digits.

The photo is not clear, but I can convince myself that the keys on the top row start at 2 and run through 9 and 0. Still no 1.

And this 1903 Olympia typewriter clearly has digits:

https://historythings.com/wp-content/uploads/2016/07/SAM_2381_clipped_rev_1....

Still no 1.

It is certainly true that many people of a certain age used to interchange 0 and O, and 1 and l, but I don't think it had anything to do with learning to type on typewriters without digits. What did they use when they needed the digits 2 through 9?

Okay, "before typewriters had number keys" is obviously wrong. Those pictures support "before typewriters had 1 keys." -- “Atoms are not things.” – Werner Heisenberg Dan Sommers, http://www.tombstonezero.net/dan

The old images I find lack the '1', but not the '0'. What model was this you had? On Sun, May 24, 2020 at 1:48 PM Rob Cliffe via Python-ideas < python-ideas@python.org> wrote:

On 22/05/2020 13:28, Steven D'Aprano wrote:

...

On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote:

...

I had a customer who was old enough to use upper case letter O for zero and lower case letter l for 1 because she was old enough to have learned to type before typewriters had number keys; that made a real mess of sorting street addresses. How old was your customer?

IIRC when I was a child, we had a typewriter that had keys for the digits 2-9, but for 0 and 1 you had to use the above trick. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/6RYKJF... Code of Conduct: http://python.org/psf/codeofconduct/

-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On 2020-05-21 05:48, Joao S. O. Bueno wrote:

Input _is_ hard or rare. Deal with it. Even the font is not uniformily configured across systems, and a glyph one does see here may not show properly on the terminal, or other

Maybe long ago. My terminals support even color emoji, have for years, and are all free. The only thing I've seen recently that doesn't is the Linux console, which I use rarely for admin tasks. (Oddly enough, it does handle right arrow properly.) fbterm is an option there for those wanting more. Even Windows 10 has gotten in on the act terminal-wise. If you're still on XP or 7, it's way past time to upgrade. -Mike

On Thu, 21 May 2020 at 18:15, Mike Miller <python-ideas@mgmiller.net> wrote:

On 2020-05-21 05:48, Joao S. O. Bueno wrote:

...

Input _is_ hard or rare. Deal with it. Even the font is not uniformily configured across systems, and a glyph one does see here may not show properly on the terminal, or other

Maybe long ago. My terminals support even color emoji, have for years, and are all free.

If you format all your computers from a single image, maybe. My pet project over the last year is a unicode art library, I use a Ubuntu 2018 and a Fedora system daily - on my personal machine, which is the Fedora, I've installed all available font packages an their kitchen sink. Still, emoji support varies wildly across terminal programs and even across the same terminal program in Ubuntu and on Fedora. Although, yes, it is likely that "older" glyphs like unicode mathematic symbols will be present in all of then and render . However, that does not mean it will render ok as a single-cell character in a mono-spaced font - as the character "east asian width" property is marked as "A" (Ambiguous), and may vary according to the installed font - even Qt5, perhaps the most sophisticated windowing toolkit available in the World, is severely bugged when displaying non single-width characters in a monospaced cell character environment such as coding space. (Of course, it may be that native Windows character and widget engines or Mac OS's are better in this particular requisite)

The only thing I've seen recently that doesn't is the Linux console, which I use rarely for admin tasks. (Oddly enough, it does handle right arrow properly.) fbterm is an option there for those wanting more.

Even Windows 10 has gotten in on the act terminal-wise. If you're still on XP or 7, it's way past time to upgrade.

I consider this thread to be moot at this time - I am just answering this e-mail because you answered me directly - but I had seem no strong support, I had seem you not answering direct questioning about how this will make things harder to learn and use but for writting down your own rationalizations on it. I'd suggest you'd just pause for a bit, and read carefully some of the other e-mails, if mine, focused mainly technical infeasibility of even typing or displaying that character, and consider these questionings for real - not with the ready made answers you have ready in your mind. I am recording a video series trying to present Python programing to absolute beginners - and to keep things timely, the ambiguity between two valid quote types is already a _pain_ - which I simply try to avoid by making consistent use of just one quote type. But after a 4 hour crash course, no one that is not already familiar with coding, could come up comfortable with using both ' or " interchangibly unless I spend 30 minutes focusing ont that.

-Mike _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/IMQFQ7... Code of Conduct: http://python.org/psf/codeofconduct/

On 2020-05-22 05:57, Joao S. O. Bueno wrote:

render . However, that does not mean it will render ok as a single-cell character in a mono-spaced font - as the character "east asian width" property is marked as "A" (Ambiguous),

Yes, though I'm sure no one is seriously proposing using wide, or combining chars, or other obscure things. Just some useful symbols from around the 0x2000 range of the BMP, which are widely/universally supported by now. To be honest, keyboard entry is the least interesting aspect of this. To reiterate, we found a zero-ongoing-effort entry method, typing and leaving " -> " in the source, and "upgrading it" to " → " with a formatter or other tool when desired. That's assuming you already have tools set up. I recommend them, but they would not be required obviously and neither would the upgraded character for compatibility reasons. More importantly, does it help readability? I think it does, however not strongly. I'm perhaps +0.5 on a few of these characters. Word processors do upgrades to hyphens, for example, to make the resulting doc more readable. Is that kind of thing useful for Python? -Mike

On Wed, May 20, 2020 at 8:36 AM Thierry Parmentelat < thierry.parmentelat@inria.fr> wrote:

Plus, it’s not only IDE’s, I’m prominently concerned by beginners and students, who start reading code on sources like github, or teaching websites, or notebooks; one cannot expect all these stacks to go this extra mile, that is just not right IMHO

= might be an improvement because that's a symbol learned in school, but

This seems to be the main (only?) argument beyond it being pretty - that it's somehow easier for beginners to deal with. I think it's the opposite. Many (probably most) people are going to come across a unicode symbol having previously only encountered ASCII symbols and probably thinking that was the only option. That includes all currently experienced Python programmers who aren't up to date on the latest news, and all beginners who learned using anything but the most up to date material. Even after this feature has been around for a while, many (most?) new learning materials will not include unicode symbols because authors don't want to go through the extra effort to write those symbols. And if you think Python is ASCII only, then when you see unicode, you'll think something is wrong. Someone's editor magically transformed `->` or the website has some overly clever rendering or something. That would be my reaction if I saw such code now. Indeed, if I copied the code and ran it with the wrong version of Python, I'd get the expected SyntaxError. Overall it just creates confusion. If you try to teach people from the beginning that both options exist, then that just slows down learning. Learning coding is hard enough for most people without being distracted by minor details about syntax. If someone thinks that special unicode symbols are the only option, or if they know they're optional but get the impression that they're preferred and feel pressure to use them, then typing code becomes a pain. In particular beginners often start coding with a basic editor such as notepad so that they aren't distracted by unneeded features or reliant on tools which do too much work for them that they need to learn on their own ( https://cseducators.stackexchange.com/a/634). So they won't have fancy IDEs to insert symbols for them, and must rely on their OS. Finally, in what way does it make it easier for beginners? `->` is pretty clearly meant to represent an arrow, but beyond that an arrow is not particularly informative. The student would still need to learn that → in that particular context is a type hint for the return value, which is not immediately obvious. Whatever difficulties they may have learning that concept, the symbol used is not going to make much difference. ≥ instead of ultimately the student still needs to learn what `>=` means as it will be used most of the time.

On 21/05/2020 15:09, Thierry Parmentelat wrote:

clearly the experienced Python programmers are not the main target here our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s, and this is Europe, not China, so...

You say that, but it is a source of endless annoyance to me that the Linux UK Keyboard doesn't offer AltGr shortcuts for a c-cedilla. It makes addressing my colleague François quite a pain :-/ -- Rhodri James *-* Kynesim Ltd

On 21/05/2020 15:29, Thierry Parmentelat wrote:

...

On 21/05/2020 15:09, Thierry Parmentelat wrote:

...

clearly the experienced Python programmers are not the main target here our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s, and this is Europe, not China, so...

You say that, but it is a source of endless annoyance to me that the Linux UK Keyboard doesn't offer AltGr shortcuts for a c-cedilla. It makes addressing my colleague François quite a pain :-/

Yeah well, if the whole english-speaking keyboard industry shares the feelings expressed on this thread, it’s no wonder ;-)

I suggest you take a look at the US-international (not sure there is a UK-international) input method, that I think is available on all 3 OSes in one form or another, and that is cool for that sort of things (the keyboard I am using right now is a regular qwerty keyboard with no alt-gr modifier)

and the other way around I can assure you that coding with a regular French keyboard - the infamous AZERTY thingy - is something you don’t want to have to do; you’d need alt-gr to enter a mere { - and digits come through shift- !

Oh, I have had to use AZERTY, while I was on holiday in Quebec. I quite agree! -- Rhodri James *-* Kynesim Ltd

On 21 May 2020, at 16:18, Alex Hall <alex.mojaki@gmail.com> wrote:

What I mean is that they would only have seen ASCII symbols used for Python syntax i.e. not counting the contents of strings.

and identifiers

Currently that's the experience of 100% of all Python coders. That percentage will drop a little if and when this feature is announced, but not much, and from there it can only decrease gradually.

Again, if I saw a unicode arrow used as syntax on GitHub or something in the wild right now, I would think it's an error, which incidentally would be correct. Wouldn't you?

yes, like I would have taken a walrus operator for a syntax error just a couple years ago maybe; things change..

That will be the experience of anyone who sees this before learning about it, and that will always include some beginners.

the only thing that beginners know is: they don’t know much, I don’t see them necessarily jumping to conclusions

21.05.20 16:45, Alex Hall пише:

≥ instead of >= might be an improvement because that's a symbol learned in school, but ultimately the student still needs to learn what `>=` means as it will be used most of the time.

But in my school I learned ⩾, not ≥. It was used in USSR and I believe in other European countries (maybe it is French or Germany tradition?). If Python will become accepting ≥ as an alias of >=, I insist that it should accept also ⩾. And ⊃, because it is the symbol used for superset relations for sets (currently written as >= in Python). And maybe other national or domain specific mathematical symbols. Imagine confusion when

=, ≥, ⩾ and ⊃ are occurred in the same program.

On Thursday, May 21, 2020 1:14 PM MRAB [mailto:python@mrabarnett.plus.com] wrote

On 2020-05-21 16:48, Serhiy Storchaka wrote:

...

21.05.20 16:45, Alex Hall пише:

...

≥ instead of >= might be an improvement because that's a symbol learned in school, but ultimately the student still needs to learn what `>=` means as it will be used most of the time.

But in my school I learned ⩾, not ≥. It was used in USSR and I believe in other European countries (maybe it is French or Germany tradition?).

⩾ is also what I learned here in the UK. ≥ _is_ clearer on-screen, though.

...

If Python will become accepting ≥ as an alias of >=, I insist that it should accept also ⩾. And ⊃, because it is the symbol used for superset relations for sets (currently written as >= in Python). And maybe other national or domain specific mathematical symbols. Imagine confusion when

...

=, ≥, ⩾ and ⊃ are occurred in the same program.

Hey, we don't have to stop there. There are lots of Unicode characters Python could accept to make it "easier". How about › and ‹ and ⁄ and ‒ and – and ͢ and ﴾ and ﴿ and ۔. (No, these are not ASCII characters)

--Edwin

On 22/05/2020 20:40, Steven D'Aprano wrote:

Imagine the confusion if somebody had variables spam, Spam, sPAM, SPam, sPAm. Or worse, SPΑM, SPАM and SPAM.

Randall is way ahead of you. https://xkcd.com/2309/ :-) -- Rhodri James *-* Kynesim Ltd

Hello, On Mon, 18 May 2020 13:25:50 +1200 Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:

On 18/05/20 1:59 am, Paul Sokolovsky wrote:

...

But even {(int): str} is a better type annotation for a function than Callable[[int], str].

I don't agree -- it looks more like some kind of dict type, and would be better reserved for that purpose.

Well, I don't say "ideal", I say "better". The point is that the world learned long ago that any type of information can be represented with just recursive parens: (foo (bar 1 (2) 3)), but some variety in punctuation helps mere humans among us.

...

And if we e.g. talk about making "->" a special operator which would allow it to appear in other contexts

Or maybe we could leverage the new walrus operator and write

str := (int)

With the idea that someone may confuse ":=" for "<-", so we can swap result and argument types comparing to their natural/intuitive order? Well, I guess that's not what I'm talking about. But we indeed can treat ":=" as a function operator in annotations, and write: (int) := str Actually, we don't have to use funky novelties, and mere "-" looks better as a lookalike for "->" than ":=". The following works as expected: ========= from __future__ import annotations def foo(f: (str, int) - int = map, seq: list = None): pass print(foo.__annotations__) import ast print(ast.dump(ast.parse(foo.__annotations__["f"]).body[0])) ========= I'd still consider it a better idea to just make "->" an operator on the AST level. Can stop there, because realistically (or sanely) PEP-0563 annotations would be parsed via an AST (example above). But if there's desire to assign some semantics to it, it can be that of making a tuple, with precedence just above "," operator, so "foo -> bar, 1 -> 2" would evaluate to ((foo, bar), (1, 2)). Worst-case, can add a __rarrow__ dunder.

-- Greg

-- Best regards, Paul mailto:pmiscml@gmail.com

IMHO, if `->` becomes an operator with semantics, then `[t1, ..., tn] -> tr` should mean `typing.Callable[[t1, ..., tn], tr]`.

I would like to comment that the graphical presentation, at least in IDEs/where the font can be controlled, can be achieved using fonts:

Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and get an arrow visually. The same can be done about getting >= as a single symbol and == and === and <=> as single symbols. It seems like a matter of code presentation, not code itself.

On Sun, 17 May 2020 at 15:45, Thierry Parmentelat < thierry.parmentelat@inria.fr> wrote:

...

On 17 May 2020, at 16:31, Bernardo Sulzbach < bernardo@bernardosulzbach.com> wrote:

I would like to comment that the graphical presentation, at least in IDEs/where the font can be controlled, can be achieved using fonts:

Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and get an arrow visually. The same can be done about getting >= as a single symbol and == and === and <=> as single symbols. It seems like a matter of code presentation, not code itself.

well, I'd find it very confusing to not be able to tell visually whether my code contains `→` or `->’ so this really is the last thing I’d want to do, personnally at least

The '→' is not going to come of nowhere, secondly, your IDE will be quite unhappy when you introduce invalid syntax and it will tell you about it, so you will able to "tell visually"

math.π instead of math.pi

That is already possible, just not done in the standard library, no? Your point still stands, but it's rather different to your other examples, which are actual changes to syntax. With regards to the actual proposal, I quite like the idea of being able to use them, but I don't think it's worth portability issues - style guides would just end up forbidding it anyway. They're also hard to type, and of course,

There should be one-- and preferably only one --obvious way to do it.

On Sun, 17 May 2020 at 13:32, Alex Hall <alex.mojaki@gmail.com> wrote:

On Sun, May 17, 2020 at 2:24 PM Thierry Parmentelat < thierry.parmentelat@inria.fr> wrote:

...

well it’s all in the title

the specific character that I am referring to is this one

In [1]: print("\u2192”) →

https://unicode-table.com/en/2192/

——

just curious about how people would feel about taking better advantage of non-ascii characters when that seems to make sense

fyi here’s how both options appear in a markdown-based website

I'm not a fan of the idea, just in case the code ends up being copied somewhere it can't be rendered properly.

If we consider the arrow, what about ≤ instead of <=, ≥ instead of >=, ≠ instead of !=, × instead of `*`, and math.π instead of math.pi? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/EKQ4WJ... Code of Conduct: http://python.org/psf/codeofconduct/

Before this goes too a big shaky bikeshed over almost nothing, let me point out that if you're looking to improve something in type annotations, I would suggest to look for true ugliness there. Something like Callable[[Dict[str, int], Sequence[Foo]], Dict[PrimaryKey, List[int]]]. That's rather unreadable.

totally agree on the awkwardness :-)

Actually, let me just quote https://docs.python.org/3/library/typing.html#typing.Callable

...

Callable type; Callable[[int], str] is a function of (int) -> str.

Lolwhat? If it's a function of "(int) -> str", then it should be written just about like that. With https://www.python.org/dev/peps/pep-0563/ , a lot of things which weren't previously possible, are now possible. Somebody should start thinking how to take advantage of that, up to allowing "(int) -> str”.

would be nice too - although this is orthogonal to my initial proposal, right ?

Which is apparently not possible currently, as while "evaluation" is postponed, it still should parse eagerly as Python syntax. But even {(int): str} is a better type annotation for a function than Callable[[int], str].

well, {(int): str} already means something; are you suggesting that an expression like this could have different meanings whether it’s in an annotation or not ? that sounds scary ...

And if we e.g. talk about making "->" a special operator which would allow it to appear in other contexts than function definition, "(int) -> str" (and other interesting annotation syntaxes) would be possible.

again, that’s be quite cool for typing function parameters :)

On 2020-05-18 02:25, Greg Ewing wrote:

On 18/05/20 1:59 am, Paul Sokolovsky wrote:

...

But even {(int): str} is a better type annotation for a function than Callable[[int], str].

I don't agree -- it looks more like some kind of dict type, and would be better reserved for that purpose.

...

And if we e.g. talk about making "->" a special operator which would allow it to appear in other contexts

Or maybe we could leverage the new walrus operator and write

str := (int)

It would be closer to the existing annotation if we could write: [int] -> str

On Tue, May 19, 2020 at 11:31 AM Brett Cannon <brett@python.org> wrote:

I'm going to ask that people please try to keep this thread on-topic to the question of using Unicode characters directly for things that we currently use two ASCII characters to represent.

Indeed -- and also: please refer to earlier conversations on this list and elsewhere -- this is NOT a new idea! I'd suggest also that the question at hand be more global: Should Python be extended to allow non-ascii characters in syntax? Rather than one or two specific ones. ON a related note, another way to get "Nicer" multi-character operatores is lignatures. Jet BRains has put out a font with a pretty full set: https://www.jetbrains.com/lp/mono/#ligatures (you can use that font with most Editors / IDEs -- works great with Sublime, for instance) That way, it's still two ascii characters, but it looks like one nifty symbol in your editor. Maybe no need to complicate Python? ;-) -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat <thierry.parmentelat@inria.fr> wrote:

I also reckon it is still cumbersome to simply enter Unicode characters from a keyboard sometimes; I guess if the big players were located in other countries that would maybe be different But that will change over time, no matter the speed, some day that will be for granted So again maybe 2020 is the right time to break that barrier ?

The Dvorak keyboard was invented nearly a hundred years ago. How's it looking as a viable alternative? If you think that a keyboard with fancy arrows on it will take off any quicker, you're extremely hopeful. MUCH more practical will be to use vim conceal etc, leave your source code unchanged, and just change the way it looks to you. There are similar features available in a number of editors. ChrisA

On Thu, May 21, 2020 at 1:48 AM Ethan Furman <ethan@stoneleaf.us> wrote:

On 05/20/2020 12:44 AM, Chris Angelico wrote:

...

On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat wrote:

...

...

I also reckon it is still cumbersome to simply enter Unicode characters from a keyboard sometimes; I guess if the big players were located in other countries that would maybe be different.But that will change over time, no matter the speed, some day that will be for granted.So again maybe 2020 is the right time to break that barrier ?

The Dvorak keyboard was invented nearly a hundred years ago. How's it looking as a viable alternative?

Well, 25 years ago I had to write my own Dvorak device driver for use with MS-DOS, now it's included in at least Windows and Linux (a Dvorak mapping, not my device driver).

So much more viable. :)

...

If you think that a keyboard with fancy arrows on it will take off any quicker, you're extremely hopeful.

I wouldn't be surprised if it did, although a standard set of keyboard shortcuts is more likely.

I'm pretty doubtful. Keyboards seem to be LOSING keys, not gaining them. Which is a trend that I deplore (where are my F1-F12 keys?? and I doubt I'll ever see F13-F16), but I still cling to the hope that not ALL keyboards are going that way. ChrisA

On 2020-05-20 00:44, Chris Angelico wrote:

If you think that a keyboard with fancy arrows on it will take off any quicker, you're extremely hopeful.

While I'm not sure how useful this is in the long run, the oft mentioned drawback of "hard to type/view" Unicode chars isn't as insurmountable as some think: - Word processors have had a palette to insert symbols for decades. - Editors have had "snippets" for perhaps almost as long. - Code formatters such as "go fmt", yapf, black, etc could update them. - All maintained OSs support a great majority of Unicode, with font support. - AltGr and Compose keys are available. I've been using Unicode everywhere for about a decade—it's time to retire the argument that input is still hard or rare. Dedicated keys are not really necessary. -Mike

On 20 May 2020, at 23:56, Steven D'Aprano <steve@pearwood.info> wrote:

...

I've been using Unicode everywhere for about a decade—it's time to retire the argument that input is still hard or rare.

I can sincerely say that I am very happy that your experience is so good, but I'm also exceedingly jealous of it. I don't think your experience scales to the majority of people.

I guess we’re getting to the gist of it I was not proposing that everybody MUST enter → I was suggesting that some people MAY want to do that so their code looks prettier in contexts where no additional intelligence is available to embellish things Do we want to get stuck in the 20th century just because everything is not yet perfect in a non-purely ASCII world ?

On 2020-05-20 14:56, Steven D'Aprano wrote:

Not everyone is programming in a GUI environment all the time

Well, I gave a number of examples to show there are many ways to do it. Not every example will work well for everyone. The best that works for your platform and tools should be chosen. There are numerous others I didn't bother to mention.

...

- Code formatters such as "go fmt", yapf, black, etc could update them.

I think this is the choice with the least effort required, a code formatter. For example, a tip was given to me that you can save keystrokes writing Python by using single-quotes exclusively (which I do) then let black change them to double later. I still come across

monospaced fonts where certain symbols have annoying "off by one pixel" display bugs, or are missing the exact symbol you need.

I use "Source code pro" often and Symbola occasionally and they work well. Full math notation is problematic and likely farther than anyone is proposing. I do use box-drawing occasionally and don't have any alignment problems with them even cross-platform.

I can sincerely say that I am very happy that your experience is so good, but I'm also exceedingly jealous of it. I don't think your experience scales to the majority of people.

It's true that I did take a few moments to configure things to make it easier for me. Once done however, easy. But, the majority is now using emoji everywhere, in defiance of curmudgeons. I've never heard anyone complain it's "too hard." -Mike

On 21 May 2020, at 14:48, Joao S. O. Bueno <jsbueno@python.org.br> wrote:

(I had a coleague once which did set a special VIM config to display "!=" as "[can't type, math 'different' sign from here]" and even that was mostly a toy than anything really useful.

I guess that is my point exactly: the main reason why this person has been unable to make anything useful out of that otherwise perfectly sound idea is that it is not allowed in the language, so people need to mess with solutions on the outside sphere - editors, IDE’s, documentation post-processing - that essentially have no chance to be sustainable, and/as it causes extra burden for everybody We should allow code to be natively pretty, and not rely on other tools to do the prettifying job - or not

On 21 May 2020, at 15:19, Joao S. O. Bueno <jsbueno@python.org.br> wrote:

That is, if you answered the question about which right arrow to use, asked above)

that’s an easy one, see the OP In [1]: print("\u2192”) → 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 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 I am convinced this will happen, one day or another, with or without Python, only question is when, not if

On 21 May 2020, at 23:03, David Mertz <mertz@gnosis.cx> wrote:

You are SERIOUSLY suggesting that typing 'Ctrl-Shift-U 2 1 9 2 <enter>' is easier for me than typing '->' as I do now!?

that’s not how I’d do it; and I dont think I said or suggested anything to that effect

And it remains easier if I use a different computer where I have to figure out or remember some different way of getting the Unicode code point into the editor?

The goal of this being to wind up with source code that will render gray boxes for unknown character if I don't have the right font or the right display context?

Even if *I* don't start using that special character (or others), I wind up having to edit and view code that other people have written, which means I need to deal with a tool stack to handle things that are hard to enter on most keyboards.

this thread seems to be obsessing on entering with the keyboard; that is not my point at all

As is... my editor looks like this. I don't type all those special things, except once in a configuration file. But the "prettification" is handled transparently when I type some ASCII sequences.

that’s nice ! it’s a real shame though, and a bit of a waste honestly, that everybody needs to cook their own brew of an editor to get there and primarily all I’m trying to say is that, one day, this will be a legal piece of code, so that we can share and enjoy exactly like this instead of in poor work-it-out-yourself ascii

On 5/21/2020 5:51 PM, Thierry Parmentelat wrote:

...

Python-arrow.png

that’s nice ! it’s a real shame though, and a bit of a waste honestly, that everybody needs to cook their own brew of an editor to get there and primarily all I’m trying to say is that, one day, this will be a legal piece of code, so that we can share and enjoy exactly like this instead of in poor work-it-out-yourself ascii Could you please explain to me how an entry method for → makes for better programmer productivity than what you call "work-it-out-yourself ascii"?  I want a specific scenario, like "1 less key press" or whatever, not some kind of "we all use emojis" hand-waving.  How would this make me a more productive programmer?  Given that -> is never going to disappear from Python anyway, how will this make the code easier to understand?

I believe I speak for a significant majority of professional programmers when I say that eye-candy like this adds no value to the language for me.  It gives me no new capabilities, I don't see it making me more productive, and we have syntax that works quite well already. What if I want to use a font in my editor that doesn't support →?  Does that mean that I won't be able to edit some random bit of code I download? --Edwin

As is... my editor looks like this. I don't type all those special things, except once in a configuration file. But the "prettification" is handled transparently when I type some ASCII sequences. [image: Python-arrow.png]

that’s nice ! it’s a real shame though, and a bit of a waste honestly, that everybody needs to cook their own brew of an editor to get there and primarily all I’m trying to say is that, one day, this will be a legal piece of code, so that we can share and enjoy exactly like this instead of in poor work-it-out-yourself ascii

The first screenshot (of completely pointless code I just typed to use a few symbols or sequences) used vim conceal plugin; also my particular configuration of what to substitute visually on screen. That approach lets entire patterns get replaced by... whatever you want. E.g. I replace `set()` with the empty-set symbol, but no one else is required to by the plugin if they don't want to (or the script Z/R for int/float, likewise). For comparison, I changed my system text editor to use JetBrains Mono Medium. The editor is called "Text Editor" on my system, but it's a rebranded gEdit, which is a pretty reasonable code editor. Someone else in the thread pointed to that font which uses ligatures to make composed characters. So it's not a substitution but simply another way of drawing some letter pairs. The result is in the attached screenshot. This approach is somewhat less flexible in that it gets exactly those ligatures that JetBrains decides you want. In concept, there is no reason this couldn't create a 'float' ligature that renders as a script R, for example. But that is not a combo JetBrains decided to use. The main point of this, is that the code is still just plain ASCII, it just happens to look "fancier." It requires no plugins, and it does not require a JetBrains IDE or editor. I haven't tried every editor, but I believe that most or all that use GUI fonts will work fine. Not sure about ligatures and Linux terminal, someone can try it. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

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

Executive summary: I'd like to make three points. 1. Accessibility matters, and I think this change would be inaccessible to users of screen readers. 2. Yes, a variety of tools imposes a burden, but also confers benefits. 3. There's no such thing as "pretty source code." There are only tools that display source code beautifully. Down and dirty details: The first is new to this discussion: Let's not make life more annoying for the accessibility developers and the people who *need* accessibility accommodations. Not all visual puns are audible puns. "→" looks like "->", but "Unicode U+2192 RIGHTWARDS ARROW" sounds nothing like "HYPHEN GREATER-THAN". (I'm guessing at the pronunciation, I don't use a screen reader myself. OK, probably the reader just says "RIGHTWARDS ARROW" or even "RIGHTARROW", but it's still not close to the same.) At the very least, we should do a case-by-case check when we want to pun this way, and also ask an accessibility expert (better three) about whether screen readers make this connection, and if not, whether their users would be able to. Second, about Tower-of-Babelonian tool proliferation: Thierry Parmentelat writes:

people need to mess with solutions on the outside sphere - editors, IDE’s, documentation post-processing - that essentially have no chance to be sustainable, and/as it causes extra burden for everybody

This situation that has no chance to be sustainable obviously *is* sustainable. It's been this way for as long as I've been using computers (daily use for work or study since 1979). I very much doubt it is going to change, ever, because tools are personal. Yes, it causes a certain amount of burden for everybody, but it also provides great benefits for everybody, or network externalities would impel us to accept a common set of tools.

We should allow code to be natively pretty, and not rely on other tools to do the prettifying job - or not

There's no such thing as code being "natively pretty". Code (source code) is a sequence of bits grouped into bytes grouped into characters grouped into statements grouped into a file. I can't see the pits on a BD or the microwaves in a wireless connection, and I doubt you can. There are software tools doing a prettifying job every time source code is displayed, printed, or read out loud, and a mass audience language like Python needs to adapt to the tools of the mass audience. Yes, we humans can help relatively "dumb" tools do a better job of displaying pretty code (for example, "significant whitespace"), but it's the quality of tool that matters most. Fred Brooks had a good essay on "sharp tools", slightly off-point, in *The Mythical Man-Month*. (I'm pretty sure of the citation but unfortunately my copies of MMM are all at school for access by my students. :-) He advocated having a tool-building specialist on his "surgical team" of (proprietary) developers, but in the open source world, we all publish our tools, which is both the glory and the disaster of something like Emacs. There are also habits that won't change -- even if *you* habitually use one of the many right arrows in Unicode instead of "->", most of us will continue to touch-type "->", and you're going to have to read it. And code is eternal: 20 years from now, somebody's going to be upset about some misfeature in the stdlib, and they're going to have to read it. (Well, maybe not "->", depends on whether they need to look at the stub files, which is a "probably not", stub files are more useful to the Python compiler than to humans most of the time.) If you want all your Python code to use non-ASCII characters in the syntax whether you wrote it or not, *your tools will have to do it for you*. Steve

On Thursday, May 21, 2020, at 8:48, Joao S. O. Bueno wrote:

On Wed, 20 May 2020 at 17:17, Mike Miller <python-ideas@mgmiller.net> wrote:

...

On 2020-05-20 00:44, Chris Angelico wrote:

...

If you think that a keyboard with fancy arrows on it will take off any quicker, you're extremely hopeful.

While I'm not sure how useful this is in the long run, the oft mentioned drawback of "hard to type/view" Unicode chars isn't as insurmountable as some think:

- Word processors have had a palette to insert symbols for decades. - Editors have had "snippets" for perhaps almost as long. - Code formatters such as "go fmt", yapf, black, etc could update them. - All maintained OSs support a great majority of Unicode, with font support. - AltGr and Compose keys are available.

I've been using Unicode everywhere for about a decade—it's time to retire the argument that input is still hard or rare. Dedicated keys are not really necessary.

Input _is_ hard or rare. Deal with it.

[...]

It seems that the only sane thing to do is to use a baseline of well established symbols on source code [...]

According to https://en.wikipedia.org/wiki/Digraphs_and_trigraphs, Python is already on thin ice by using the full set of ASCII characters. I wonder how many non-native English speakers have given up on Python because of that. I'm old enough to remember terminals that didn't support lower case letters, let alone "curly braces," and to have used dozens of different keybpards with all sorts of "common" symbols (e.g., [, {, /, \, <) in all sorts of different places. I had a customer who was old enough to use upper case letter O for zero and lower case letter l for 1 because she was old enough to have learned to type before typewriters had number keys; that made a real mess of sorting street addresses. But I digress. Sort of. Yes, some characters are harder to enter for some people at some times. We're all different, and so are our computing tools. Imagine that. When I studied Koine Greek in school (c. 2003 or 2004), I learned what I had to to type up my homework. Was I fast? No, not really. Was I fast enough? Yep. I'm not for full blown, use every Unicode character we can, but I'm not against using characters outside the ISO 646 invariant character set, either. Using π or ϖ as an alias for math.pi? Not too bad. Matched pairs of left/right quotation marks? Maybe, but not without a lot more thought. Different right arrows for different operations? That's asking for trouble. -- “Atoms are not things.” – Werner Heisenberg Dan Sommers, http://www.tombstonezero.net/dan

On Friday, May 22, 2020, at 8:28, Steven D'Aprano wrote:

On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote:

...

I had a customer who was old enough to use upper case letter O for zero and lower case letter l for 1 because she was old enough to have learned to type before typewriters had number keys; that made a real mess of sorting street addresses.

https://historythings.com/life-changing-invention-typewriters/

I can see 0, 2, 3, 4, 5, and 6 clearly. I can't see a 1, although it appears that the key between the 0 and the Q is missing its label.

https://historythings.com/wp-content/uploads/2016/07/9999006136-l.jpg

The photo isn't clear enough to see the keys, but there are 44 of them. Since the Sholdes typewriter didn't have lowercase letters, it's hard to imagine what the remaining keys after the uppercase letters and punctuation marks were if they weren't digits.

The photo is not clear, but I can convince myself that the keys on the top row start at 2 and run through 9 and 0. Still no 1.

And this 1903 Olympia typewriter clearly has digits:

https://historythings.com/wp-content/uploads/2016/07/SAM_2381_clipped_rev_1....

Still no 1.

It is certainly true that many people of a certain age used to interchange 0 and O, and 1 and l, but I don't think it had anything to do with learning to type on typewriters without digits. What did they use when they needed the digits 2 through 9?

Okay, "before typewriters had number keys" is obviously wrong. Those pictures support "before typewriters had 1 keys." -- “Atoms are not things.” – Werner Heisenberg Dan Sommers, http://www.tombstonezero.net/dan

The old images I find lack the '1', but not the '0'. What model was this you had? On Sun, May 24, 2020 at 1:48 PM Rob Cliffe via Python-ideas < python-ideas@python.org> wrote:

On 22/05/2020 13:28, Steven D'Aprano wrote:

...

On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote:

...

I had a customer who was old enough to use upper case letter O for zero and lower case letter l for 1 because she was old enough to have learned to type before typewriters had number keys; that made a real mess of sorting street addresses. How old was your customer?

IIRC when I was a child, we had a typewriter that had keys for the digits 2-9, but for 0 and 1 you had to use the above trick. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/6RYKJF... Code of Conduct: http://python.org/psf/codeofconduct/

-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On 2020-05-21 05:48, Joao S. O. Bueno wrote:

Input _is_ hard or rare. Deal with it. Even the font is not uniformily configured across systems, and a glyph one does see here may not show properly on the terminal, or other

Maybe long ago. My terminals support even color emoji, have for years, and are all free. The only thing I've seen recently that doesn't is the Linux console, which I use rarely for admin tasks. (Oddly enough, it does handle right arrow properly.) fbterm is an option there for those wanting more. Even Windows 10 has gotten in on the act terminal-wise. If you're still on XP or 7, it's way past time to upgrade. -Mike

On Thu, 21 May 2020 at 18:15, Mike Miller <python-ideas@mgmiller.net> wrote:

On 2020-05-21 05:48, Joao S. O. Bueno wrote:

...

Input _is_ hard or rare. Deal with it. Even the font is not uniformily configured across systems, and a glyph one does see here may not show properly on the terminal, or other

Maybe long ago. My terminals support even color emoji, have for years, and are all free.

If you format all your computers from a single image, maybe. My pet project over the last year is a unicode art library, I use a Ubuntu 2018 and a Fedora system daily - on my personal machine, which is the Fedora, I've installed all available font packages an their kitchen sink. Still, emoji support varies wildly across terminal programs and even across the same terminal program in Ubuntu and on Fedora. Although, yes, it is likely that "older" glyphs like unicode mathematic symbols will be present in all of then and render . However, that does not mean it will render ok as a single-cell character in a mono-spaced font - as the character "east asian width" property is marked as "A" (Ambiguous), and may vary according to the installed font - even Qt5, perhaps the most sophisticated windowing toolkit available in the World, is severely bugged when displaying non single-width characters in a monospaced cell character environment such as coding space. (Of course, it may be that native Windows character and widget engines or Mac OS's are better in this particular requisite)

The only thing I've seen recently that doesn't is the Linux console, which I use rarely for admin tasks. (Oddly enough, it does handle right arrow properly.) fbterm is an option there for those wanting more.

Even Windows 10 has gotten in on the act terminal-wise. If you're still on XP or 7, it's way past time to upgrade.

I consider this thread to be moot at this time - I am just answering this e-mail because you answered me directly - but I had seem no strong support, I had seem you not answering direct questioning about how this will make things harder to learn and use but for writting down your own rationalizations on it. I'd suggest you'd just pause for a bit, and read carefully some of the other e-mails, if mine, focused mainly technical infeasibility of even typing or displaying that character, and consider these questionings for real - not with the ready made answers you have ready in your mind. I am recording a video series trying to present Python programing to absolute beginners - and to keep things timely, the ambiguity between two valid quote types is already a _pain_ - which I simply try to avoid by making consistent use of just one quote type. But after a 4 hour crash course, no one that is not already familiar with coding, could come up comfortable with using both ' or " interchangibly unless I spend 30 minutes focusing ont that.

-Mike _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/IMQFQ7... Code of Conduct: http://python.org/psf/codeofconduct/

On 2020-05-22 05:57, Joao S. O. Bueno wrote:

render . However, that does not mean it will render ok as a single-cell character in a mono-spaced font - as the character "east asian width" property is marked as "A" (Ambiguous),

Yes, though I'm sure no one is seriously proposing using wide, or combining chars, or other obscure things. Just some useful symbols from around the 0x2000 range of the BMP, which are widely/universally supported by now. To be honest, keyboard entry is the least interesting aspect of this. To reiterate, we found a zero-ongoing-effort entry method, typing and leaving " -> " in the source, and "upgrading it" to " → " with a formatter or other tool when desired. That's assuming you already have tools set up. I recommend them, but they would not be required obviously and neither would the upgraded character for compatibility reasons. More importantly, does it help readability? I think it does, however not strongly. I'm perhaps +0.5 on a few of these characters. Word processors do upgrades to hyphens, for example, to make the resulting doc more readable. Is that kind of thing useful for Python? -Mike

On Wed, May 20, 2020 at 8:36 AM Thierry Parmentelat < thierry.parmentelat@inria.fr> wrote:

Plus, it’s not only IDE’s, I’m prominently concerned by beginners and students, who start reading code on sources like github, or teaching websites, or notebooks; one cannot expect all these stacks to go this extra mile, that is just not right IMHO

= might be an improvement because that's a symbol learned in school, but

This seems to be the main (only?) argument beyond it being pretty - that it's somehow easier for beginners to deal with. I think it's the opposite. Many (probably most) people are going to come across a unicode symbol having previously only encountered ASCII symbols and probably thinking that was the only option. That includes all currently experienced Python programmers who aren't up to date on the latest news, and all beginners who learned using anything but the most up to date material. Even after this feature has been around for a while, many (most?) new learning materials will not include unicode symbols because authors don't want to go through the extra effort to write those symbols. And if you think Python is ASCII only, then when you see unicode, you'll think something is wrong. Someone's editor magically transformed `->` or the website has some overly clever rendering or something. That would be my reaction if I saw such code now. Indeed, if I copied the code and ran it with the wrong version of Python, I'd get the expected SyntaxError. Overall it just creates confusion. If you try to teach people from the beginning that both options exist, then that just slows down learning. Learning coding is hard enough for most people without being distracted by minor details about syntax. If someone thinks that special unicode symbols are the only option, or if they know they're optional but get the impression that they're preferred and feel pressure to use them, then typing code becomes a pain. In particular beginners often start coding with a basic editor such as notepad so that they aren't distracted by unneeded features or reliant on tools which do too much work for them that they need to learn on their own ( https://cseducators.stackexchange.com/a/634). So they won't have fancy IDEs to insert symbols for them, and must rely on their OS. Finally, in what way does it make it easier for beginners? `->` is pretty clearly meant to represent an arrow, but beyond that an arrow is not particularly informative. The student would still need to learn that → in that particular context is a type hint for the return value, which is not immediately obvious. Whatever difficulties they may have learning that concept, the symbol used is not going to make much difference. ≥ instead of ultimately the student still needs to learn what `>=` means as it will be used most of the time.

On 21/05/2020 15:09, Thierry Parmentelat wrote:

clearly the experienced Python programmers are not the main target here our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s, and this is Europe, not China, so...

You say that, but it is a source of endless annoyance to me that the Linux UK Keyboard doesn't offer AltGr shortcuts for a c-cedilla. It makes addressing my colleague François quite a pain :-/ -- Rhodri James *-* Kynesim Ltd

On 21/05/2020 15:29, Thierry Parmentelat wrote:

...

On 21/05/2020 15:09, Thierry Parmentelat wrote:

...

clearly the experienced Python programmers are not the main target here our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s, and this is Europe, not China, so...

You say that, but it is a source of endless annoyance to me that the Linux UK Keyboard doesn't offer AltGr shortcuts for a c-cedilla. It makes addressing my colleague François quite a pain :-/

Yeah well, if the whole english-speaking keyboard industry shares the feelings expressed on this thread, it’s no wonder ;-)

I suggest you take a look at the US-international (not sure there is a UK-international) input method, that I think is available on all 3 OSes in one form or another, and that is cool for that sort of things (the keyboard I am using right now is a regular qwerty keyboard with no alt-gr modifier)

and the other way around I can assure you that coding with a regular French keyboard - the infamous AZERTY thingy - is something you don’t want to have to do; you’d need alt-gr to enter a mere { - and digits come through shift- !

Oh, I have had to use AZERTY, while I was on holiday in Quebec. I quite agree! -- Rhodri James *-* Kynesim Ltd

On 21 May 2020, at 16:18, Alex Hall <alex.mojaki@gmail.com> wrote:

What I mean is that they would only have seen ASCII symbols used for Python syntax i.e. not counting the contents of strings.

and identifiers

Currently that's the experience of 100% of all Python coders. That percentage will drop a little if and when this feature is announced, but not much, and from there it can only decrease gradually.

Again, if I saw a unicode arrow used as syntax on GitHub or something in the wild right now, I would think it's an error, which incidentally would be correct. Wouldn't you?

yes, like I would have taken a walrus operator for a syntax error just a couple years ago maybe; things change..

That will be the experience of anyone who sees this before learning about it, and that will always include some beginners.

the only thing that beginners know is: they don’t know much, I don’t see them necessarily jumping to conclusions

21.05.20 16:45, Alex Hall пише:

≥ instead of >= might be an improvement because that's a symbol learned in school, but ultimately the student still needs to learn what `>=` means as it will be used most of the time.

But in my school I learned ⩾, not ≥. It was used in USSR and I believe in other European countries (maybe it is French or Germany tradition?). If Python will become accepting ≥ as an alias of >=, I insist that it should accept also ⩾. And ⊃, because it is the symbol used for superset relations for sets (currently written as >= in Python). And maybe other national or domain specific mathematical symbols. Imagine confusion when

=, ≥, ⩾ and ⊃ are occurred in the same program.

On Thursday, May 21, 2020 1:14 PM MRAB [mailto:python@mrabarnett.plus.com] wrote

On 2020-05-21 16:48, Serhiy Storchaka wrote:

...

21.05.20 16:45, Alex Hall пише:

...

≥ instead of >= might be an improvement because that's a symbol learned in school, but ultimately the student still needs to learn what `>=` means as it will be used most of the time.

But in my school I learned ⩾, not ≥. It was used in USSR and I believe in other European countries (maybe it is French or Germany tradition?).

⩾ is also what I learned here in the UK. ≥ _is_ clearer on-screen, though.

...

If Python will become accepting ≥ as an alias of >=, I insist that it should accept also ⩾. And ⊃, because it is the symbol used for superset relations for sets (currently written as >= in Python). And maybe other national or domain specific mathematical symbols. Imagine confusion when

...

=, ≥, ⩾ and ⊃ are occurred in the same program.

Hey, we don't have to stop there. There are lots of Unicode characters Python could accept to make it "easier". How about › and ‹ and ⁄ and ‒ and – and ͢ and ﴾ and ﴿ and ۔. (No, these are not ASCII characters)

--Edwin

On 22/05/2020 20:40, Steven D'Aprano wrote:

Imagine the confusion if somebody had variables spam, Spam, sPAM, SPam, sPAm. Or worse, SPΑM, SPАM and SPAM.

Randall is way ahead of you. https://xkcd.com/2309/ :-) -- Rhodri James *-* Kynesim Ltd

Hello, On Mon, 18 May 2020 13:25:50 +1200 Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:

On 18/05/20 1:59 am, Paul Sokolovsky wrote:

...

But even {(int): str} is a better type annotation for a function than Callable[[int], str].

I don't agree -- it looks more like some kind of dict type, and would be better reserved for that purpose.

Well, I don't say "ideal", I say "better". The point is that the world learned long ago that any type of information can be represented with just recursive parens: (foo (bar 1 (2) 3)), but some variety in punctuation helps mere humans among us.

...

And if we e.g. talk about making "->" a special operator which would allow it to appear in other contexts

Or maybe we could leverage the new walrus operator and write

str := (int)

With the idea that someone may confuse ":=" for "<-", so we can swap result and argument types comparing to their natural/intuitive order? Well, I guess that's not what I'm talking about. But we indeed can treat ":=" as a function operator in annotations, and write: (int) := str Actually, we don't have to use funky novelties, and mere "-" looks better as a lookalike for "->" than ":=". The following works as expected: ========= from __future__ import annotations def foo(f: (str, int) - int = map, seq: list = None): pass print(foo.__annotations__) import ast print(ast.dump(ast.parse(foo.__annotations__["f"]).body[0])) ========= I'd still consider it a better idea to just make "->" an operator on the AST level. Can stop there, because realistically (or sanely) PEP-0563 annotations would be parsed via an AST (example above). But if there's desire to assign some semantics to it, it can be that of making a tuple, with precedence just above "," operator, so "foo -> bar, 1 -> 2" would evaluate to ((foo, bar), (1, 2)). Worst-case, can add a __rarrow__ dunder.

-- Greg

-- Best regards, Paul mailto:pmiscml@gmail.com

IMHO, if `->` becomes an operator with semantics, then `[t1, ..., tn] -> tr` should mean `typing.Callable[[t1, ..., tn], tr]`.

I would like to comment that the graphical presentation, at least in IDEs/where the font can be controlled, can be achieved using fonts:

Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and get an arrow visually. The same can be done about getting >= as a single symbol and == and === and <=> as single symbols. It seems like a matter of code presentation, not code itself.

On Sun, 17 May 2020 at 15:45, Thierry Parmentelat < thierry.parmentelat@inria.fr> wrote:

...

On 17 May 2020, at 16:31, Bernardo Sulzbach < bernardo@bernardosulzbach.com> wrote:

I would like to comment that the graphical presentation, at least in IDEs/where the font can be controlled, can be achieved using fonts:

Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and get an arrow visually. The same can be done about getting >= as a single symbol and == and === and <=> as single symbols. It seems like a matter of code presentation, not code itself.

well, I'd find it very confusing to not be able to tell visually whether my code contains `→` or `->’ so this really is the last thing I’d want to do, personnally at least

The '→' is not going to come of nowhere, secondly, your IDE will be quite unhappy when you introduce invalid syntax and it will tell you about it, so you will able to "tell visually"