Behavior of the for-else construct

[Chris Angelico]

On Fri, 4 Mar 2022 at 11:39, Avi Gross via Python-list
<python-list at python.org> wrote:
>
> Rob,
>
> I regularly code with lots of comments like the one you describe, or mark the end of a region that started on an earlier screen such as a deeply nested construct.
>
> I have had problems though when I have shared such code and the recipient strips my comments and then later wants me to make changes or even just explain it! My reply tends to be unprintable as in, well, never mind!
>

If they strip out the comments, you can be confident that the comments
were unhelpful :)

> This leads to a question I constantly ask. If you were free to design a brand new language now, what would you do different that existing languages have had to deal with the hard way?
>

Very good way to start thinking. In fact, I'd recommend going further,
and actually designing the entire language. (Don't bother actually
writing an implementation, but fully lay out the syntax and
semantics.) It's a great exercise, and you'll learn why things are the
way they are.

> I recall when filenames and extensions had a limited number of characters allowed and embedded spaces were verboten. This regularity made lots of code possible but then some bright people insisted on allowing spaces and you can no longer easily do things like expand *.c into a long line of text and then unambiguously work on one file name at a time. You can often now create a name like "was file1.c and now is file2.c" and it seems acceptable. Yes, you can work around things and get a vector or list of strings and not a command line of text and all things considered, people can get as much or more work done.
>

I don't remember when embedded spaces were verboten, so I'm guessing
you're talking about 1970s or earlier, on mainframes? In MS-DOS, it
was perfectly possible to have spaces in file names, and OS/2 also had
that flexibility (and used it for special files like "EA DATA. SF" on
a FAT disk). Windows forbade a bunch of characters in file names, but
other systems have always been fine with them.

It's not only file names that can be multiple words in a single
logical argument. The Windows "start" command has a bizarreness where
it takes a quoted string as a title, but a second quoted string as a
file name, so <<start c:\some_dir>> will open that directory, <<start
"c:\some_dir">> opens a shell with a title of "c:\some_dir", and
<<start "" "c:\some_dir">> opens the directory, even if it has spaces
in it. It's much better to treat arguments as a vector of strings
rather than a single string, as the start command tries to.

> 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.
>

Tell me, which is more important: the way the code looks, or the way
it is typed? Because your *editor* can control both of these.

> So I would love to see some key that allows you to do something like L* to mean the combination is a left bracket and should be treated as the beginning of a sequence expected to end in R* or perhaps *R. That would allow many other symbols to be viewed as balanced entities. Think of how Python expanded using single and double quotes (which arguably might work better if balanced this way) to sometimes using triple quotes to putting letters like "b" or "f" in front to make it a special kind of string.
>

Okay. Design that in an editor and see if it catches on.

I've seen a wide variety of bracket-matching tools (like color-coding
all types of bracket according to what they pair with), but none of
them really get popular. Baking it into the language means that
everyone who uses the language has to be able to work with this.

Flesh out this "L*" idea, and explain how it solves the problem. What
does it do to the asterisk?

> But I suspect programming might just get harder for those who would not appreciate a language that used (many) hundreds of symbols. I do work in many alphabets and many of them pronounce and use letters that look familiar in very different ways and sound them differently and invent new ones. Every time I learn another human language, I have to both incorporate the new symbols and rules and also segregate them a bit from identical or similar things in the languages I already speak. It can be quite a chore. But still, I suspect many people are already familiar with symbols such as from set Theory such as subset and superset that could be used as another pair of parentheses of some type Having a way to enter them using keyboards is a challenge.
>

Exactly.

> Back to the topic, I was thinking wickedly of a way to extend the FOR loop with existing keywords while sounding a tad ominous is not with  an ELSE but a FOR ... OR ELSE ...
>

for victim in debtors:
    if victim.pay(up): continue
    if victim.late(): break
or else:
    victim.sleep_with(fishes)

There's something in this.

ChrisA