On Wed, Jan 19, 2022 at 9:47 AM Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Jan 18, 2022 at 07:40:40AM -0700, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
On 2022-01-18 at 12:07:15 +1100, Steven D'Aprano <steve@pearwood.info> wrote:
I would be more sympathetic to this idea if:
1. I knew how to easily type all those brackets on the keyboard, without having to use a GUI character picker.
That's between you and your OS.
Is there any other Python syntax which is likewise OS-dependent?
Not sure about Python, but C and C++ have digraphs and trigraphs as alternatives for certain symbols, specifically because some OS/keyboard/language combinations may not be able to easily type the originals. Over time, a particular set of symbols seems to have settled in as the standard ones that most programmers can use, such that anyone who can't easily type them will learn how to work around that problem. For example, REXX supports two spellings of its negation operator: REVERSE SOLIDUS "\" and NOT SIGN "¬", but almost nobody uses the latter. Would love to hear from people whose keyboards lack these characters.
Okay. Without looking it up, how would *you* type ⟮ U+27EE "Mathematical Left Flattened Parentheses"? On your honour now, don't look it up.
Be careful: don't give people the codepoint number in these challenges, because a lot of input systems let you enter any character by keying in the codepoint. Here's a better challenge: Type five unique open parenthesis signs, without looking up their key sequences or codepoints.
Do you think that the majority of Python programmers, especially beginners, will be keen to memorize a dozen or so key combinations to write parentheses and brackets?
One crucial question is whether the different types of brackets would have semantic meaning or not. 1) No semantic difference: the various characters are all absolutely equivalent to ( or ). This is the easiest and safest, but also kinda useless. 2) Real, crucial semantic difference: unique symbols that have special meaning (like using a pair of non-ASCII brackets to surround a frozenset literal). 3) Optional semantic difference: 【1, 2, 3】 is exactly the same as (1, 2, 3), but 【1, 2, 3) would be an error. In the first case, nobody needs to learn input methods, since they can just use other types of bracket no problem. But this is useless. You can get nearly all the same benefit by using the same brackets everywhere and then getting your editor to colour them for you. The second definitely forces people to learn the symbols, although if the use-cases are sufficiently rare, it might not be a big deal to copy and paste them ("you can make frozenset literals by using these symbols, or just use the word frozenset"). The third is an interesting hybrid, and if Python supported it, I would definitely make use of it in a few places. There are times when it'd be nice to be able to mark a specific call or something, thus creating a boundary within a sea of close parentheses. Trouble is, that kind of code shows up more in my JavaScript than in my Python, so it wouldn't be all that helpful :) But still, there would be places I'd use it in Python.
Someone on this list keeps saying that everyone wants to know how to play the piano, but that no one wants to put in the hard work to learn to play the piano. ;-)
I read close to every email on this list and I've never seen anyone use that phrase before. Maybe I've missed it. Or maybe you're thinking of another list?
Maybe it's one of the people who's banned from the list, and is only seen on the newsgroup? I haven't seen that turn of phrase either.
In this wonderful world of the Internet era, where code collaboration, sharing of open-source software, and forums where people can post code for public viewing, how do I know that the parentheses and brackets I choose will be visible to all my readers?
If I post code asking for help "why am I getting a SyntaxError here?"
spam(1, eggs(2, cheese(3, fe(), fi(), fo())))
using fancy Unicode parentheses, how do I know that the people I am asking for help will see what I see, instead of
spam 1, eggs 2, cheese 3, fe , fi , fo
or
spam□1, eggs□2, cheese□3, fe□□, fi□□, fo□□□□□
or similar?
If a popular language makes use of a particular set of characters, there would be a strong push to support those characters in code editors. I think it's not a problem to expand that set occasionally, as long as there's enough justification for it.
We have to live in the world we have, not the world we want. Given the state of Unicode support in typefaces, editors, IDEs, web forum software, etc, what percentage of the time do you think that using fancy parentheses would *enhance* communication and collaboration, rather than degrade it?
Font choice is already an important consideration with code sharing. Can we get a list of the most popular fonts for reading code in (whether in editors, code review tools, collaboration tools, etc)? I grabbed this by peeking at GitHub's commit view: "ui-monospace,SFMono-Regular,SF Mono,Menlo,Consolas,Liberation Mono,monospace". The last one is a fallback; I'm not sure what ui-monospace is, but it's probably a generic alias that says "whatever the user has selected as the monospace font in the UI". Editors and IDEs - if they don't support Unicode and some of the popular encodings (mainly UTF-8), they're not going to be able to adequately render Python code anyway, so I don't have a problem with blaming the tool there. Web forum software - sigh. That one is unsolvable, since there are so many of them. But maybe there are a few syntax highlighter modules that can be checked? With collaboration tools that aren't code-specific, the current state of affairs is *already* terrible. Sidebar chat usually drops newlines and indentation, and often mangles quotes and spaces too. With code-specific tools, they're usually going to be IDE-like or editor-like, so I would say that they need proper Unicode support just the same. So ultimately, it's a font issue. How do we survey fonts to see which ones support which characters? ChrisA