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 <[email protected]>
To: [email protected]
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
