Comments (9)
continue
makes more sense to me as "continue trying more matches". Blindly jumping into the next match block causes all sorts of problems with missing variable extractions, etc. Besides, it's nothing that couldn't already be done with union patterns.
I also like using break
this way, and the two are a natural pair. It seems very symmetric that there's an implicit break
at the end of a block, similar to an implicit return
at the end of a function.
from patma.
It is also ironically echoing C's use of break
in switch
statements. :-)
from patma.
There is one downside to giving continue
and break
in match statement special meaning: there is a common code pattern where one loops over some values and has an if ... elif ... else
on the value. There are two problems if some of the branches has continue
or break
statements:
- When one refactor such
if ... elif ... else
into a match statement, thosecontinue
andbreak
suddenly change meaning (in a somewhat subtle way). - Even when one is well aware about semantics of
continue
andbreak
in match statements it will be awkward to achieve the desired semantics in a loop.
Thinking about my own experience, I wanted to break out of an if ... elif ... else
chain quite rarely, while I wanted to break or continue a loop from such chain quite often. Also I think that most use cases for proposed continue
semantics can be achieved using guards or assignment expression or |
patterns.
Together, I think this may be a strong argument in favor of making continue
and break
target the enclosing loop rather than the match statement itself.
from patma.
I agree.
from patma.
One aspect of break
and continue
that I really do not like is that it forces the individual cases into an order. Although this is clearly beyond the scope of what we are currently doing in Python, most languages with pattern matching compile it down to something like a finite state machine. That is, a simple example like this:
match x:
case foo(2): ...
case foo(3): ...
case bar(a): ...
is actually compiled down to hierarchical code like this:
if isinstance(x, foo):
if foo.arg == 2: ...
elif foo.arg == 3: ...
elif isinstance(x, bar):
....
Introducing break
and continue
as operators on the match statement would make such optimisations much harder. Yes, I know that this would be nearly impossible to do with our proposal in Python, but I still feel that break
and continue
do not fit the overall notion of pattern matching.
Anyway, I also fully agree with that match statements are more likely to contain a break
or continue
to affect a surrounding loop, as Ivan noted. In fact, I first considered using a for
loop for my own implementation of case
as it seems to be almost ideally suited for that purpose (the iterator can return either zero or one element, which would be a tuple with the values for variables to bind). However, the fact that such a for
loop would capture any break
s and continue
s made me look for a different way and abandon that idea.
So, long story short, I would not include break
and continue
as part of pattern matching.
from patma.
@brandtbucher -- any final words about this? Otherwise I propose to label this as "rejected".
from patma.
Nope, great points have been made. I agree that the drawbacks outweigh the benefits.
from patma.
Let's keep rejected issues open though. I like to have the full discussion visible.
from patma.
Agreed - a rejected issue is not 'closed' because there is still work to be done - writing up the reason why it was rejected.
(If an issue had no impact at all on the PEP, then I suppose theoretically we could close it.)
from patma.
Related Issues (20)
- Phrasing update in abstract and overview HOT 2
- Disallow guards when using an "open pattern"? HOT 11
- Can the compiler move guards around? HOT 7
- JSON example HOT 5
- Add link to DLS paper to PEP 635 HOT 1
- Reach out to Pablo for code review HOT 1
- Use "as" for named patterns HOT 2
- Raise SyntaxErrors for anything following irrefutable patterns
- Finish AST validation for patterns
- Catch remaining errors in the compiler HOT 1
- Unify the PEP 634 and implementation grammars HOT 2
- Review progress for the reference implementation HOT 5
- Thomas Wouters' objections HOT 13
- Nick Coghlan's (revised) PEP 642 HOT 1
- Dedicated AST nodes for patterns? HOT 5
- PyCon 2021 HOT 10
- work error with zip param "strict=False" on py386 HOT 1
- Please document the design decisions behind PEP 634. HOT 7
- Case goto's? HOT 1
- PyCon JP 2021 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from patma.