Chris, Much of what I intended is similar to what you say. I am simply saying the existing group of programmers seems to include people who will not see every thing the same way. There is no way to make them all happy and you have other constraints like not suddenly adding new reserved words, so you do the best you can and hope people can get educated.
I have seen lots of otherwise bright people drop out of math classes not because they could not understand the concepts, but because they have trouble handling all the symbols being used, such as Greek letters. Often they get stuck simply because nobody tells them how to pronounce the letter as in epsilon or zeta or aleph. Or consider the many ways various people denote a derivative. For some f'(x) and f''(x) feel right but dy/dx and d^2y/dx^2 (assume since this is plain next, I meant a small superscript 2 representing squared) makes no sense. Others like it the other way and still others like a dot on top of something like an s or two dots. I can mix and match many such representations because I know they are just representations of an underlying thing that I do understand. I have seen people then get stuck at partial derivatives which use a new symbol instead of the d, whose name they do not know like ∂ Teaching APL also drove some students crazy with all the overprinted symbols. So, yes, using ELSE in what seems to them like multiple and incompatible ways can lead to frustration but is rather unavoidable. Which leads to a point you misunderstood. I was saying R reserved a namespace of sorts so that adding new keywords could be done safely. Users are not expected to make variable names like %in% so you can write code like if (var %in% listing) and you can even change the definition in a sort of overloading to do something different. YES this can lead to others puzzling over your code. But if you need a new keyword, perhaps you could expand into such a reserved corner of the namespace and avoid having to reuse existing key words in possibly incompatible, or at least for some non-intuitive, ways. It does not need to use percent signs, just some notation users would normally not already be using. I am not here to say R is better, just some ideas are very different and thus many things chosen now are not inevitable. It gives me some flexibility in say calling a function as `[`(args) instead of [args] and rewriting it. Python plays lots of similar games, such as the decorators you like to use. In many places, Python makes it easier for me to do things. There really are more like three kinds of Programmers. Some see the world one way and some another way and some are switch hitters. The fourth kind tend not to be programmers! The ones who are adaptable and simply acknowledge that a decision has been made and use the functionality as it is done, do best. No need to complain, just adapt. And, of course, you can just not use anything that does not appeal to you but do not be shocked if you encounter code by others who are using it and be ready to understand it enough for the purpose at hand. If Python was being designed TODAY, I wonder if a larger set of key words would be marked as RESERVED for future expansion including ORELSE and even NEVERTHELESS. -----Original Message----- From: Chris Angelico <ros...@gmail.com> To: python-list@python.org <python-list@python.org> Sent: Thu, Mar 3, 2022 7:34 pm Subject: Re: Behavior of the for-else construct 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. 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 -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
