On 04/03/2022 00:34, Chris Angelico wrote:
On Fri, 4 Mar 2022 at 10:09, Avi Gross via Python-list
<python-list@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.
Or those who have a vague fuzzy idea about it and have trouble
remembering what it does.
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.
You could add examples ad nauseam. I submit that for-else is a special
case. As evidenced by the number of people (including me) who say they
have trouble grokking it.
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.
No. "finally" suggests (as analogy to try...finally) that the "finally"
suit body is always executed. Presumably even if an untrapped exception
occurs in the for-loop body (or even in the for-loop iterator). A
for-loop can be terminated with "break" for many conceptually different
reasons e.g.
A search for a suitable item has found one.
Something unexpected has happened.
A pre-set allowed execution time has been exceeded.
"nobreak"/"no_break" etc. is explicit and conceptually neutral.
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.
+0.9, although I do sometimes wish for a macro feature in Python. Like,
say, one that would translate "nobreak" into "else". 😁
(Import hooks, and tools like MacroPy, can be used for this sort of
effect.
I haven't tried MacroPy yet, maybe someday I will.
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?
It would be easy to read if they were spelt sensibly, e.g.
if_no_iterations:
if_one_iteration:
if_multiple_iterations:
if_any_iterations:
if_break:
if_no_break:
(I'm not saying that all of these are desirable, just conveying the idea.)
If multiple clauses were triggered, they should be executed in the order
in which they occur in the code.
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
Of course you have. There are three types of programmer: those that can
count, and those that can't.
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list
