My point Chris was that you can have a conversation where you are exploring and not proposing. Brainstorming, perhaps.
I was saying that there are many ways to signal things and in some hypothetical new language, it may be implemented in novel ways that do not break anything. I note languages like JavaScript seem to love passing functions or setting event handlers that may only be activated under unusual conditions. So my POINT (and I repeat NOT a suggestion) is that I can IMAGINE ways to add a feature to a loop, such as an extra optional argument that is called if the loop exits from the bottom. The code you now put in the ELSE clause might have to be in the lambda or whatever. That may not be a good fit for Python. What may aggravate you is that lots of people keep telling you that the ELSE on a loop feature is not intuitive to many, sometimes even after it is explained. My suggestion is you should deal with that and not take it out on others. Live and let live. My view remains that something has been added and is available and won't likely be changed so use it as-is or ignore it. But if anyone wants to make their own language, they can feel free to design around this any way they wish. If they design an object that encapsulates a loop and then add attributes to the object that are guaranteed to tell you how the loop ended and run some code if it is set there, fine. This forum may be about Python but not exclusively. I personally often enjoy hearing how some other system does something similar, such as discussions on how and whether Python should allow an underscore in static numbers given other languages do so, not always identically. We can learn from such comparisons, for good and also for bad. I am NOT proposing we change anything about ELSE and that was not my point. My point was that sometimes rather than reuse an existing keyword in the language or create new reserved keywords, there can be many possible ways to extend functionality. I know of languages with multiple variations on loops that do not break existing code. If your syntax is for (...) { ...} then if you add the ability to place some identifier ONLY in the context involved then for XXX (...) { ...} may mean some altered functionality while YYY in the same spot means something else and the original form continues to do what it always did. So are XXX and YYY keywords or something else? Again, I do not understand why people here get so touchy. But if it makes you happy, take me off this list! I have so many things I need to do and free up time for. -----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail....@python.org> On Behalf Of Chris Angelico Sent: Sunday, October 16, 2022 6:56 PM To: python-list@python.org Subject: Re: for -- else: what was the motivation? On Mon, 17 Oct 2022 at 08:22, <avi.e.gr...@gmail.com> wrote: > I had another crazy thought that I AM NOT ASKING anyone to do. OK? > Here's another proposal: Let's ban you from this mailing list. Don't worry, I AM NOT ASKING anyone to do it. OK? Do you see how ridiculous and pointless it is to have proposals with that kind of caveat? Make serious proposals that we can discuss reasonably, don't make fake proposals and hide behind a caveat. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list