[Python-ideas] Allow additional separator character in variables

[Stephen J. Turnbull]

Mikhail V writes:

 > BTW, as per Serhiy Storchaka's note:
 > 
 > my·variable
 > my%Gᝍ%@variable
 > my%Gã
¡%@variable
 > my%Gⵧ%@variable
 > my%Gㄧ%@variable
 > my%Gㆍ%@variable
 > 
 > ^ Is this good idea *for Python*?

Given that 5 of 6 show up with the glyph for U+FFFD REPLACEMENT
CHARACTER in my client, I'd say not (but then, I can always fix my
mail client so don't mind me ;-).

 > I don't know how it is possible. Looks like a result of some
 > unlucky nuclear experment. Might be it will not cause any possible
 > confusion, or less than a hyphen and a minus.

It depends on how familiar people and tools are with Unicode.  For
example, after almost clicking on something from "Apple.co.jp" where
the "A" is from the Cyrillic block, my mail program now highlights
confusables (there's a list at Unicode.org) and also places where
languages I don't use are present in the message preview.  It really
helps in detecting spam!  But most people neither have that knowledge,
nor the source code to their mail clients and browsers, to help them
with those distinctions.

Personally, I think that Python probably should ban non-ASCII
non-letter characters in identifiers and whitespace, and maybe add
them later in response to requests from native speakers of the
relevant languages.  I don't know how easy that would be to do,
though, since I think the rule is already that identifiers must be
composed only of letters, numbers, and ASCII "_".  Since Serhiy's
examples are valid, we'd have to rule them out explicitly, rather than
by reference to the Unicode database.  Yuck.

 > If the new language thing would happen and gained popularity - it
 > would be the worst scenario - competing syntaxes, CO2 emissions,
 > community splittage, etc.  I don't endorse such ideas.

Think of it as evolution in action.

So, languages evolve whether you do it yourself or not.  It's not a
question of you endorsing the idea.  Eventually somebody will write a
better language than Python.  Why not you?

The problem, if it's similar to an existing one, is the work it
creates for the author of the new language.  The worst possible case
is something like Python 3.  IIUC, Guido's opinion now is that looking
back, Python 3 was the right thing to do at the time but he's never
gonna do that again, too much work on explaining "why Python 3".  The
question would be, is it right for *you* to do it for a language with
your favorite features?  I don't say you *should*, just that you
*could*.

Regards,

Steve