Behavior of the for-else construct

[Avi Gross]

Since we still seem to be dreaming, I wonder when someone will suggest using some variation of the new match statement. All you need is for the for loop (and possibly other such constructs) to return some kind of status that can be matched

match (for var in something:
                ... ) :
  case break():
  case skipped():
  case did(1):
  case didall():

  case crash():
  case _ :

As always, the above is not even pseudocode. But my point is there are languages I have seen that are built on such pattern matching and provide abilities to do a multi-way branching as long as you are very careful about the order you place the things to match.

If not understood, the above function calls are meant to suggest something. For argument's sake, the for loop could return a non-negative number that shows the number of iterations done completely or even partially. It could also return various out-of-band (perhaps negative) values. So if it is skipped you get a zero or a value matching what my make-believe function skipped() returns. If the loop just ran once, it matched did(1).  If it completed without breaks, it didall() and if it broke out, or crashed it matches something. I hope the idea comes across, even if you disagree with my indenting or exact method.

Constructs like the above do in theory allow some really complex matching and often in a way easier to understand than having endless clauses added below the for group. 

But as repeatedly stated, Python currently has no concept of returning a value directly from a for loop or lots of other things. A brand new language that superficially resembled python could be designed but that is a rather formidable task.

And where does it end? I mean you could set it up so the language allows you to return an invisible (meaning it does not print unless you ask for it) object among many possible objects. 

The simplest object may be an integer or perhaps an object of a class with a name like counter so you matched against counter(1) or against counter(n) if you want to capture the exact number for further processing. Various other object types might be returned including one that tells you about a break and also on which iteration it broke out of or even the value of the  item it was looping on at the moment. If this starts looking a bit like how errors can be created and propagated, that is no coincidence.

But the above also might come with serious overhead. And for many, it would not be seen as necessary. I will say that by allowing the match statement in the current form, the door has been opened wide for all kinds of potential enhancements. Older code and features may be left alone, but newer code is now free to do esoteric things. If I rewrote my call to the loop into a function that takes arguments including the data I want to have used and internally does the for loop while setting various variables that capture all kinds of info needed, then it potentially could return one of a series of objects you could pattern match against to your heart's content. A call to the function could be used in a match statement vaguely as in my hand-waving above. And of course you can use unpacking to make all kinds of compound patterns if done carefully.

I think my part of this endless conversation may have gone a bit beyond far enough and I await some new topics.


-----Original Message-----
From: Rob Cliffe via Python-list <python-list at python.org>
To: python-list at python.org
Sent: Sat, Mar 5, 2022 7:15 am
Subject: Re: Behavior of the for-else construct




On 05/03/2022 01:15, Cameron Simpson wrote:
>
> I sort of wish it had both "used break" and "did not use break"
> branches, a bit like try/except/else.
And "zero iterations".
Rob Cliffe

-- 
https://mail.python.org/mailman/listinfo/python-list