[Python-ideas] Non-ASCII in Python syntax? [was: Null coalescing operator]

[Mikhail V]

Steven D'Aprano wrote:

> I cannot wait for the day that we can use non-ASCII operators. But I
> don't think that day has come: it is still too hard for many people
> (including me) to generate non-ASCII characters at the keyboard, and
> font support for some of the more useful ones are still inconsistent or
> lacking.

> For example, we don't have a good literal for empty sets. How about ∅?
> Sadly, in my mail client and in the Python REPR, it displays as a
> "missing glyph" open rectangle. And how would you type it?

I will just share my view on the whole problematic, trying to
concentrate more on the actual code look.
So I see it all as a chain of big steps, roughly:

1. One defines *the real code* or syntax, this means:
  One takes a pen and a paper (photoshop/paint bucket)
  and *defines* the syntax, this means one defines everything
  as it is, including pixel precise spaces between operators,
  punctuation and so on.

2. One develops an application (IDE) which enables you to
  automatically load code file and (at least) view it
  *exactly* as you have defined it.

3. Only after that one starts to think about ASCII/unicode/Hangul
  (forgive me Lord) or whatever someone has defined as something
useful/standard.

> Java, I believe, allows you to enter escape sequences in source code,
> not just in strings. So we could hypothetically allow one of:
>
>    myobject\N{WHITE SQUARE}attribute
>    myobject\u25a1attribute
>
> as a pure-ASCII way of getting
>
>    myobject□attribute


So this actually would be a possible kind of "bridge" from the real code
to what is shown up in arbitrary text editing application or a mailing client.

In other words, you believe that in Unicode table you'll find something
useful for code definition, but I personally would not even start
relying on that, also because it is merely down-top problem solving.


Mikhail