Behavior of the for-else construct

[Avi Gross]

I am not sure a reply is needed, Peter, and what you say is true. But as you point out, when using a German keyboard, I would  already have a way to enter symbols like ä, ö, ü and ß and no reason not to include them in variable names and so on if UNICODE is being used properly. I can use my last name in German notation as a variable in Python now:

Groß = 144
Groß / 12
12.0

But even if I was German (and despite living in Austria for a year, I am not) I might want to write some things in French which might not be on that Keyboard, unless it includes everything in ISO 8859-1, albeit that standard is missing letters used rarely in some languages.

I have also used characters from Spanish and French and Hungarian and others as names in programs with no problems, albeit getting them in is not trivial on my very solid American English keyboard but can be done many ways. A fairly simple way is to use something like this using Google translate:

https://translate.google.com/?sl=de&tl=en&op=translate

Pick the language you want and pop up a keyboard and type a bit and then copy/paste like this: גרוס

If I had to do this all the time, and occasionally I do, you can get other pop-up keyboards or helpers that take several keystrokes you memorize and convert it, ...

But it rarely is worth doing this if others will be using my code and complaining or trying to edit it. 

Chris has already pointed out the dangers of wandering too far from standard practice and making code hard for anyone else to deal with so yes, I would not rewrite key components or do something like make new function names that point to existing standard functions and only use the new (often not pronounceable) names. 


-----Original Message-----
From: Peter J. Holzer <hjp-python at hjp.at>
To: python-list at python.org
Sent: Fri, Mar 4, 2022 5:57 pm
Subject: Re: Behavior of the for-else construct

On 2022-03-04 00:38:22 +0000, Avi Gross via Python-list wrote:
> I have seen major struggles to get other character sets into
> languages. Any new language typically should have this built in from
> scratch and should consider adding non-ASCII characters into the mix.
> Mathematicians often use lots of weird braces/brackets as an example
> while normal programs are limited to [{( and maybe < and their
> counterparts. This leads to odd Python behavior (other languages too)
> where symbols are re-used ad nauseam. { can mean set or dictionary or
> simply some other way to group code.

I think the main reason for this is that people have to be able to type
the code. I do remember the days when German keyboards didn't have
brackets and braces and you had to type alt-123 to get a {. Made it real
fun to program in C ...

If you design a language and in IDE together (the way Smalltalk was
designed back in the 1970s or maybe Visual Basic) you can use all sorts
of funky characters because you can also provide a standard way to enter
them. But if you expect your users to type programs in a standard text
editor (even a fancy one like Emacs or Vim or VS Code), you have to
restrict yourself to a character set that most people can comfortably
type on their keyboards with the key mapping provided by their OS. Which
for historical reasons means US-ASCII.

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"


-- 
https://mail.python.org/mailman/listinfo/python-list