On Wed, Jan 19, 2022 at 9:47 AM Steven D'Aprano <st...@pearwood.info> wrote:
>
> On Tue, Jan 18, 2022 at 07:40:40AM -0700, 2qdxy4rzwzuui...@potatochowder.com 
> wrote:
> > On 2022-01-18 at 12:07:15 +1100,
> > Steven D'Aprano <st...@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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/SQUMLWHBO3A5IJYMXHHMXVEYDYFJRMRJ/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to