Behavior of the for-else construct

[Chris Angelico]

On Fri, 4 Mar 2022 at 10:09, Avi Gross via Python-list
<python-list at python.org> wrote:
>
> The drumbeat I keep hearing is that some people hear/see the same word as implying something else. ELSE is ambiguous in the context it is used.
>

What I'm hearing is that there are, broadly speaking, two types of
programmers [1]:

1) Those who think about "for-else" as a search tool and perfectly
understand how it behaves
2) Those who have an incorrect idea about what for-else is supposed to
do, don't understand it, and don't like it.

You could easily make a similar point about a lot of other advanced
constructs. Some people don't understand threading, and either dislike
it or are scared of it. Some people never get their heads around
asyncio and the way that yield points work. Some people can't grok
operator precedence, so they parenthesize everything "just to be
safe". And some people dislike exceptions so much that they warp all
their functions into returning a (value,True) or (error,False) tuple
instead. Does this mean that all these features are bad? No.

There's no way to make every feature perfectly intuitive to every
programmer. Those features are still incredibly useful to the
programmers that DO use them.

Maybe, with hindsight, for-finally would have been a slightly better
spelling than for-else. Who knows. But people simply need to
understand it, just like people need to understand how binary
floating-point works, and claiming that it's "ambiguous' is simply
wrong. It has one meaning in the language, and then if programmers
have an incorrect expectation, they need to learn (or to not use the
feature, which isn't really a problem, it's just not taking advantage
of it).

> And naturally, since nobody desperately wants to use non-reserved keywords, nobody seems ready to use a word like INSTEAD instead.
>
> Ideally, a language should be extendable and some languages like R allow you to place all kinds of things inside percent signs to make new operators like %*% or %PIPE% ...
>

I don't know what you mean by "extendable", but if you mean that
different people should be able to change the language syntax in
different ways, then absolutely not. When two different files can be
completely different languages based on a few directives, it's
extremely difficult to read.

(Import hooks, and tools like MacroPy, can be used for this sort of
effect. I do not think that we should be using them on a regular basis
to change core syntax.)

> Just because some feature may be wanted is not a good reason to overly complicate a language. Can you imagine how hard it would be both to implement and read something like:
>
> ...
> ELSE:
>    ...
> OK:
>    ...
> FINALLY:
>    ...
> ULTIMATELY:
>    ...
>
> What if multiple of things like the above example need to be triggered in some particular order?

I don't know what they'd all mean, but if they were all in the core
language, they would have to be supported in arbitrary combinations.
It's possible to have a "try-except-else-finally" block in Python, for
instance. But if you mean that they should all do what "else" does
now, then this is a terrible idea. One way of spelling it is just
fine.

> This reminds me a bit of how some programs add so much functionality because someone thought of it without wondering if anyone (including the ones who sponsored it) would ever want to use it or remember it is there or how. I recall how a version of emacs had a transpose-letter function so after typing "teh" you could hit control-t and a little mock LISP macro would go back and co a cut and go forward and do a paste and leave the cursor where it was. That was sometimes useful, but often just as easy to backspace and retype. But I recall gleefully adding a transpose for words, sentences, paragraphs and was going to add more but I was running out of keystrokes to bind them to and besides it can be fairly easy to select items and yank them and move to where you want them and replace them.
>

SciTE has a "transpose lines" feature. I use it frequently. But editor
features are quite different from language features.

ChrisA

[1] Something tells me I've heard this before