Well, I finally ran into a Python Unicode problem, sort of

[John Ladasky]

On Sunday, July 3, 2016 at 12:42:14 AM UTC-7, Chris Angelico wrote:
> On Sun, Jul 3, 2016 at 4:58 PM, John Ladasky wrote:

> Very good question! The detaily answer is here:
> 
> https://docs.python.org/3/reference/lexical_analysis.html#identifiers
> 
> > A philosophical question.  Why should any character be excluded from a variable name, besides the fact that it might also be an operator?
> 
> In a way, that's exactly what's happening here. Python permits certain
> categories of character as identifiers, leaving other categories
> available for operators. Even though there aren't any non-ASCII
> operators in a vanilla CPython, it's plausible that someone could
> create a Python-based language with more operators (eg ≠ NOT EQUAL TO
> as an alternative to !=), and I'm sure you'd agree that saying "≠ = 1"
> is nonsensical.

I agree that there are some characters in the Unicode definition that could (should?) be operators and, as such, disallowed in identifiers.  "≠", "≥" and "√" come to mind.  I don't know whether the Unicode "character properties" are assigned to the characters in a way that would be satisfying to the needs of programmers.  I'll do some reading.

> Symbols like that are a bit of a
> grey area, so you may find that you're starting a huge debate :)

Oh, I can see that debate coming.  I know that not all of these characters are easily TYPED, and so I have to reach for a Unicode table to cut and paste them.  But once but and pasted, they are easily READ, and that's a big plus.

Here's another worm for the can.  Would you rather read this...

d = sqrt(x**2 + y**2)

...or this?

d = √(x² + y²)