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@python.org>
To: python-list@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

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

Reply via email to