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 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/

Hello, On Sun, 17 May 2020 14:31:34 +0200 Alex Hall wrote: []

If we consider the arrow, what about ≤ instead of <=, ≥ instead of

...

=, ≠ instead of !=, × instead of `*`, and math.π instead of math.pi?

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. 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". 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]. 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. -- Best regards, Paul mailto:pmiscml@gmail.com

On 17 May 2020, at 16:31, Bernardo Sulzbach 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

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"

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 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 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 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.

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.

I'll have to look into that. -- ~Ethan~

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 Wed, May 20, 2020 at 01:13:10PM -0700, Mike Miller 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.

Not everyone is programming in a GUI environment all the time, and even when they are, GUI "insert symbol palettes" are of greatly variable quality.

- Editors have had "snippets" for perhaps almost as long.

Sure, but like the "insert symbol" command, needing to use a snippet adds friction. Even in the best case, think of the difference between: * type a minus sign `-` * use a snippet or symbol palette to find and insert a `→` symbol.

- Code formatters such as "go fmt", yapf, black, etc could update them. - All maintained OSs support a great majority of Unicode, with font support.

Which is still patchy, but getting better. 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 a lot of arrows in my maths equations, and they are invariably too small, too big or placed too close to the baseline, depending on the font. At smaller font sizes, the arrow head tends to look like "grit on the monitor". In a word processor, I can manually tweak that, but in a programming environment using a text editor, there's not much I can do except search for that One Perfect Font. Still not found it after decades of searching.

- AltGr and Compose keys are available.

And require the editor or OS to support it, a keyboard to have the right compose key, and most importantly of all, for the user to remember a bunch of esoteric key codes to get the symbol needed. I can remember Win key .. to give MIDDLE DOT · but it's the wrong dot, I need DOT PRODUCT ⋅ (which unfortunately is displayed as a missing- character glyph in my email client and editor). But I have no idea what key combination I need to press to get DOT PRODUCT. Last night I had one of my students ask me how they are supposed to type maths symbols during an online test if they can't google for it and copy it from some website. I didn't have an answer. So what is the key code for the → symbol?

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. -- Steven

On Wed, 20 May 2020 at 17:17, Mike Miller 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. 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 editing environment. I see absolutely no gain of using optional arcane symbols in soruce code. Of course documentation derived from annotations can be as prettified as one want. It seems that the only sane thing to do is to use a baseline of well established symbols on source code, and anyone can have a customized editor to render (or input) those as they see fit - and even thought that always have been a possibility, very few people does so. (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.

-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/OD4CI5... Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, 21 May 2020 at 10:06, Thierry Parmentelat wrote:

...

On 21 May 2020, at 14:48, Joao S. O. Bueno 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

And then, suppose you can "solve" this chicken and egg problem by allowing it on the language. Get 2 or 3 years for people to catch on the language version that accepts it (how much code out there using 1_000_000 numric spacing already?) - then, supposing tools evolve along with it, ok, maybe in 4 years I can fire-up a "visual studio code" with a setup that allows me to hold a modifier key and pops-up a floating virtual keyboard with the unicode operators and type it almost seamlessly - how would that help me to type code snippets in e-mails or web-forms??? That is effectivelly locking people out of the language unless they have a "proper coding tool" - which likely would also be needed to display code properly. (may I remind you that some of these symbols are not even on the basic BMP so it is not feasible to use them in idle. That is, if you answered the question about which right arrow to use, asked above) Whereas the same effort for a 'magic symbol palette' plugin for vscode, pycharm or whatever is the IDE of the moment can support displaying the ASCII operators as unicode, in the way it is already possible with VI - while keeping the source code editable when I ssh into a docker container with misconfigured keyboard settings.

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 May 2020, at 15:45, Alex Hall wrote:

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.

I’m having a hard time with statements like

Many (probably most) people are going to come across a unicode symbol having previously only encountered ASCII symbols

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... what was the point of defining unicode in the first place then ?

On Thu, May 21, 2020 at 4:09 PM Thierry Parmentelat < thierry.parmentelat@inria.fr> wrote:

...

On 21 May 2020, at 15:45, Alex Hall wrote:

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.

I’m having a hard time with statements like

...

Many (probably most) people are going to come across a unicode symbol having previously only encountered ASCII symbols

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...

what was the point of defining unicode in the first place then ?

What I mean is that they would only have seen ASCII symbols used for Python syntax i.e. not counting the contents of strings. 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? That will be the experience of anyone who sees this before learning about it, and that will always include some beginners.

Hello, On Thu, 21 May 2020 13:26:32 +0200 Thierry Parmentelat wrote: []

Do we want to get stuck in the 20th century just because everything is not yet perfect in a non-purely ASCII world ?

Short answer: yes. Long answer: ASCII was defined in 1963 and hasn't won over yet, e.g. EBCDIC is alive and kicking: https://en.wikipedia.org/wiki/EBCDIC . Ergo, 50 years isn't enough for a character encoding to become truly pervasive. I suggest we wait and see whether 100 years makes a difference, which in the case of Unicode means: let's talk again closer to 22th century. [] -- Best regards, Paul mailto:pmiscml@gmail.com

On 21 May 2020, at 16:18, Alex Hall 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

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

...

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..

I think you make a good point, but it's not quite the same. If I see: ``` if (match := re.match(...)): x = match.group(1) ``` and I don't know what `:=` means, I pretty much have to Google it, guess, or otherwise learn. I'm not going to think that a colon was accidentally added to `match = re.match(...)` because that's not valid syntax either. I *might* think it's supposed to be `match == re.match(...)`, but that would just raise more questions - `match` is an undefined variable, and you don't compare match objects. Besides, how did this mistake happen? Didn't this person run their code? If I see: ``` def foo() → Bar: ``` I'm going to think that either: 1. Some fancy rendering is going on, like the ligatures some have been talking about. Right *now*, that's probably the most likely hypothesis, considering that some people do this in their editors. If it was actually valid syntax, I'd be surprised when that reasonable guess turned out wrong, especially if I paste it somewhere and get a SyntaxError with my slightly outdated Python. Which leads me to the next guess... 2. In the process of transferring from the editor to a blog/email/document/etc the code has been mangled. I don't know exactly how, but someone was complaining on this list recently that plain ASCII quotes had turned into fancy matching quotes which lead to a confusing error message. So it seems plausible that `->` got transformed somehow. It's not similarly plausible that `==` randomly became `:=`.

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.

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 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 21 May 2020, at 23:03, David Mertz 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 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

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.

This speaks for me. Not only such an addition requires substantial support, which it doesn't seem to be gathering, it requires some quantitative evidence that this is better than what we already have in some meaningful aspect.

On Thu, 21 May 2020 at 18:15, Mike Miller 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 Fri, May 22, 2020 at 11:02 PM Joao S. O. Bueno wrote:

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.

Seriously? In primary school English class I learned that you can nest quotations by using different quote characters. Maybe we need to consider that first-grade English (or whatever your native language is) should be considered a prerequisite for coding, and just teach those kinds of concepts (including words like "singular" and "plural", since they're so helpful for diagnosing bugs). ChrisA

On Fri, May 22, 2020 at 11:21 AM David Mertz wrote:

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 ability to pretty-ify code in this way is inspiring; I'm going to have to look into it. There could be many other IMO more useful/helpful pretty-fication ideas out there that could not be accomplished with unicode, or simple "replace these symbols with another one" configurations. Couple of examples: 1. I've often thought it would be nice if the parameter type-hints sort of floated underneath (or maybe above? underneath makes more sense to me) the parameter names, rather than using the colon at all. Or, perhaps using colors to specify types - Indigo for ints, scarlet for strings, fuchsia for floats, perhaps italics for optionals, that sort of thing. 2. Another really nice improvement, so that I could share raw, copy-and-pasted pretty-ified code with my professional engineering coworkers (as a set of engineering calculations), would be for the editor to detect mathematical equations and display them that way. Like: from scipy.integrate import quad def f(x, i, j, a, b): return quad(a*x**2 + b , 0, 1, args=(a,b)) ...would be displayed *automatically* (without having to muck about with sympy), and able to be copied, as: [image: image.png] ( latex code: $f=\int_{i}^{j} a x^2 + b \,dx$ ) *BACK ON TOPIC:* The point of giving the examples above is not to rabbit trail, but to agree with others who have basically said going down this particular road-- putting a lot of effort into including fancy unicode symbols as part of the syntax-- would be a mistake. IMO, a big reason it would be a mistake is, it doesn't bring *ENOUGH* to the table for making things look nicer-- there is so much more that could be done to make reading python an even more pleasurable experience beyond using unicode symbols. And not only that, make it useful to more people beyond the circle of those who actually even *KNOW* they are reading "python" (as opposed to just English pseudocode describing mathematical/algorithmic processes). --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler

On 22/05/2020 18:21, Mike Miller wrote:

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?

Generally speaking, no. Editors that do things for you behind your back are an open invitation to bugs. I find that for most word processing that I do, I have to turn off the automatic translation/correction/whatever to prevent them from incorrectly rewriting my input. Prettifying code so that it no longer runs when you cut and paste is one example; more often I find they mangle the capitalisation of company names, product ID and so forth. I would hate to find an editor starting to do similar things for me. Sometimes even basic things like "electric modes" (auto-indentation after you hit RETURN) can make more work for you! -- Rhodri James *-* Kynesim Ltd

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

On 5/23/2020 8:52 AM, Stephen J. Turnbull wrote:

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.) Microsoft Narrator totally skips → when I got it to read the subject line on this email (Result:  "I'd like to suggest allowing unicode as an alternative to 'dash'").  There might be other screen readers that work better, but I agree that this would increase inaccessibility.

--Edwin

Hello, On Mon, 18 May 2020 02:39:27 +0100 MRAB wrote: []

...

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

To make it clear, the talk is about "better", not "existing" annotation syntax, which is a square (literally) peg in a round hole. With PEP 0563, there's totally no need to wrap everything in square brackets, and atrocities like __class_getitem__ can be treated like an implementation detail of a particular Python implementation (CPython, that is). With PEP 0563, while evaluating annotations, one can just pass to eval() a suitably constructed "globals" dict, to enable any operators on any symbols (which would be represented by objects, not classes), or just operate on AST with even finer level of control. -- Best regards, Paul mailto:pmiscml@gmail.com

On 24/05/20 10:26 am, Paul Sokolovsky wrote:

On Mon, 18 May 2020 13:25:50 +1200 Greg Ewing wrote:

...

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?

No, with the idea of making use of an already-legal expression and not introducing any new syntax into the grammar.

But we indeed can treat ":=" as a function operator in annotations, and write:

(int) := str

But that would be backwards with respect to the flow of data when := is used for assignment. Also, it is not currently legal syntax when there is more than one argument, because := doesn't support unpacking. -- Greg

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.

The old images I find lack the '1', but not the '0'.  What model was this you had? Sorry, no way I can remember that far back.  I'm not even certain about

On 24/05/2020 19:01, David Mertz wrote: the missing 0.

On Sun, May 24, 2020 at 1:48 PM Rob Cliffe via Python-ideas mailto: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 mailto:python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org mailto: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.