TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

PEP 622 – Structural Pattern Matching

285 点作者 kragniz将近 5 年前

25 条评论

justusw将近 5 年前
Very interesting. This PEP is still in draft state, but I am interested to see how the community will react. For me, I have a few thoughts:<p>1) This is really close to Erlang&#x2F;Elixir pattern matching and will make fail-early code much easier to write and easier to reason about.<p>2) match&#x2F;case means double indentation, which I see they reasoned about later in the &quot;Rejected ideas&quot;. Might have a negative impact on readability.<p>3) Match is an already used word (as acknowledged by the authors), but I think this could have been a good case for actually using hard syntax. For me, perhaps because I&#x27;m used to it, Elixir&#x27;s &quot;{a, b, c} = {:hello, &quot;world&quot;, 42}&quot; just makes sense.<p>4) I hope there won&#x27;t be a big flame-war debacle like with :=<p>5) And then finally there is the question of: &quot;It&#x27;s cool, but do we really need it? And will it increase the surprise factor?&quot; And here I&#x27;m not sure. And again, this was the concern with the new assignment expression. The assignment expression is legitimately useful in some use cases (no more silly while True), but it might reduce the learnability of Python. Python is often used as an introductory programming language, so the impact would be that curricula need to be adjust or beginner programmers will encounter some surprising code along the road.<p>I can&#x27;t say this is a good or bad proposal, I want to see what other opinions are out there, and what kind of projects out there in the world would really benefit from syntax like this.
评论 #23629071 未加载
评论 #23627841 未加载
评论 #23636746 未加载
mdrachuk将近 5 年前
So it’s actually a smart switch statement.<p>Seems like it doesn’t create instances when you’re doing<p><pre><code> Node(children=[Leaf(value=&quot;(&quot;), Node(), Leaf(value=&quot;)&quot;)]) </code></pre> instead:<p>1. Node means &quot;is instance of Node&quot;.<p>2. Everything in between () is &quot;has an attribute with value&quot;.<p>3. List means &quot;the attribute should be treated as a tuple of&quot;.. etc..<p>Very confusing, this definitely needs another syntax, because both newcomers and experienced devs will be prone to read it as plain `==`, since that&#x27;s how enums and primitives will be working.<p>This syntax goes against Zen: It’s implicit -- when using match case expressions don&#x27;t mean what they regularly mean. It’s complicated -- basically it’s another language (like regex) which is injected into Python.<p>I’m a big believer in this feature, it just needs some other syntax. Using {} instead of () makes it a lot better. Now no way to confuse it with simple equality.<p><pre><code> match node: case Node{children=[{Leaf{value=&quot;(&quot;, Node{}, ...}}</code></pre>
评论 #23630607 未加载
评论 #23629327 未加载
评论 #23629067 未加载
评论 #23627997 未加载
评论 #23629692 未加载
评论 #23636363 未加载
评论 #23628592 未加载
uryga将近 5 年前
glad to see this! though it&#x27;s a shame that the proposed `match&#x2F;case` is a statement, not an expression:<p>&gt; &quot;We propose the match syntax to be a statement, not an expression. Although in many languages it is an expression, being a statement better suits the general logic of Python syntax.&quot;<p>no matching in lambdas unless those get overhauled too :(<p>instead, let&#x27;s get excited for a whole bunch of this:<p><pre><code> match x case A: result = &#x27;foo&#x27; case B: result = &#x27;bar&#x27; </code></pre> (i guess i&#x27;m a <i>little</i> salty...)
评论 #23628999 未加载
评论 #23628564 未加载
评论 #23627167 未加载
评论 #23630155 未加载
MattConfluence将近 5 年前
Lately, Elixir has dethroned Python as the language that I get the most joy from using. Pattern matching in one of the big reasons. Great to see that Python core contributors (including Guido!) wants to see this feature in Python as well! Hopefully it will be well integrated and not feel like a tacked on feature.<p>If you&#x27;re curious about why this is so useful, and reading the (quite dry) PEP isn&#x27;t your thing, I would heartily recommend playing with Elixir for a few hours. Pattern matching is a core feature of the language, you won&#x27;t be able to avoid using it. The language is more Ruby-like than Python-like, but Python programmers should still have an easy time grokking it. When I was getting started I used Exercism [1] to have some simple tasks to solve.<p>[1] <a href="https:&#x2F;&#x2F;exercism.io&#x2F;tracks&#x2F;elixir" rel="nofollow">https:&#x2F;&#x2F;exercism.io&#x2F;tracks&#x2F;elixir</a>
sicromoft将近 5 年前
This PEP is burying the lede -- it introduces a `@sealed` decorator, which gives python ADTs: <a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0622&#x2F;#sealed-classes-as-adts" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0622&#x2F;#sealed-classes-as-...</a>
评论 #23635980 未加载
mkl将近 5 年前
&quot;The match and case keywords are proposed to be soft keywords, so that they are recognized as keywords at the beginning of a match statement or case block respectively, but are allowed to be used in other places as variable or argument names.&quot;<p>That&#x27;s interesting. Python 3.6 had &quot;async&quot; and &quot;await&quot; as soft keywords, before they became reserved keywords in 3.7 [1]. However, soft keywords have just been added to Python more generally [2], so aren&#x27;t such a special case anymore.<p>[1] <a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0530&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0530&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;python&#x2F;cpython&#x2F;pull&#x2F;20370" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;python&#x2F;cpython&#x2F;pull&#x2F;20370</a>, <a href="https:&#x2F;&#x2F;github.com&#x2F;python&#x2F;cpython&#x2F;pull&#x2F;20370&#x2F;files" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;python&#x2F;cpython&#x2F;pull&#x2F;20370&#x2F;files</a>
aparmentier将近 5 年前
Interesting proposal, but I&#x27;m cringing at yet another overload for the * symbol.<p>a * b == &quot;a times b&quot;<p>a * * b == &quot;a to the power of b&quot;<p>f(* a) == &quot;call f by flattening the sequence a into args of f&quot;<p>f(* * a) == &quot;call f by flattening the map a into key value args for f&quot;<p>[* a] == &quot;match a sequence with 0 or more elements, call them a&quot;<p>Am I missing something? I know these all occur in different contexts, still the general rule seems to be &quot;* either means something multiplication-y, or means &#x27;having something to do with a sequence&#x27; -- depends on the context&quot;. It&#x27;s getting to be a bit much, no?<p>Note: HN is making me put spaces between * to avoid interpretation as italics.
评论 #23630573 未加载
评论 #23630614 未加载
评论 #23630749 未加载
评论 #23631012 未加载
BiteCode_dev将近 5 年前
So far I like it.<p>Unpacking was huge 10 years ago, but nowaday even JS has object destructuring, so python was lagging behind.<p>It feels like they really spent a lot of time in designing this: Python has clearly not be made for that, and they have to balance legacy design with the new feature.<p>I think the matching is a success in that regard, and the __match__ method is a great idea. The guards will be handy, while the &#x27;_&#x27; convention is finally something official. And thanks god for not doing the whole async&#x2F;await debacle again. Breaking people&#x27;s code is bad.<p>On the other hand, I understand the need for @sealed, but this is the kind of thing that shows that Python was not designed with type hints from the begining. Haskell devs must have a laught right now.<p>We can thank Guido for the PEG parser in 3.9 whichs allows him to co-author this as well.<p>I expect some ajustments to be made, because we will discover edge cases and performance issues, for sure. Maybe they&#x27;ll change their mind on generalized unpacking: I do wish to be able to use that for dicts without having to create a whole block.<p>But all in all, I believe it will be the killer feature of 3.10, and while I didn&#x27;t see the need to move from 3.7, walrus or not, 3.10 will be my next target for upgrade.
csantini将近 5 年前
If you want it today, Pampy does most of it:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;santinic&#x2F;pampy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;santinic&#x2F;pampy</a><p>Even match on Point(x, y, _)
评论 #23634671 未加载
评论 #23629419 未加载
评论 #23630243 未加载
sitkack将近 5 年前
If you like pattern matching and Python, I recommend you check out <a href="http:&#x2F;&#x2F;coconut-lang.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;coconut-lang.org&#x2F;</a> which compiles to Python.
评论 #23627802 未加载
评论 #23635874 未加载
whalesalad将近 5 年前
This is the first PEP I’m really excited about. I hope the design is given more careful consideration, though, because destructuring in this manner more broadly across the language would also be killer.<p>My biggest concern is the class matching syntax. I feel like that would be much better deferred to a lambda style function or similar. The syntax matches instantiating a new class instance exactly, which seems like it could cause a lot of problems for tools that read and manipulate syntax.
hnlmorg将近 5 年前
Can someone explain to me the history behind Python&#x27;s aversion to switch statements? I get Python is opinionated and I&#x27;m not trying to start a language war, it was just never clear to me why the `if ... elif` pattern was the preferred idiom.
评论 #23627909 未加载
评论 #23627499 未加载
评论 #23627844 未加载
评论 #23627529 未加载
评论 #23627556 未加载
评论 #23637297 未加载
评论 #23628733 未加载
jjice将近 5 年前
Rust was my first experience with pattern matching, and I really learned to love it there. Seeing it come to Python will be great as well. I&#x27;m glad this is on the docket, and I can&#x27;t wait to see how this draft evolves.
henryiii将近 5 年前
I&#x27;m excited, but it seems like setting names by default is very odd. Quite a bit of the PEP is dedicated to the odd situations created by &quot;case x&quot; actually setting x rather than reading x (&quot;case .x&quot; would read x). Wouldn&#x27;t this be a natural place for := ? So you would do:<p><pre><code> case x := _ </code></pre> to match and assign to x. &quot;_&quot; would always be the matcher. You always have access to the original item that the match was made on, so pulling out the matched items is often not needed, AFAICT. This would be explicit, and not too surprising. Then the whole dotted names part can be dropped - it works like normal Python at that point.<p>The PEP already suggests this for capturing parts of the match, why not just use it for all saved matches? It&#x27;s more verbose, but consistent, with fewer caveats, and not always needed.<p>Disclaimer: My languages don&#x27;t happen to include one with good pattern matching, so I&#x27;m not strongly familiar with it.
评论 #23644025 未加载
lincolnq将近 5 年前
This is very exciting!<p>One subtle thing which I noticed is the distinction between class patterns and name patterns (bindings). In particular, it is possibly confusing that the code `case Point:` matches anything and binds it to the value Point, whereas `case Point():` checks if the thing is an instance of Point and doesn’t bind anything.
评论 #23629086 未加载
Spiritus将近 5 年前
Note that this just a draft&#x2F;proposal. And there&#x27;s heavy activity on the mailing list.<p>With that said, this has been suggested and discussed many times in the past. I imagine this will be as controversial as the walrus operator[1] was.<p>[1] <a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0572&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0572&#x2F;</a>
Narann将近 5 年前
&gt; case Node(children=[LParen(), RParen()]):<p>Is this will create a second Node instance and compare it to node?<p>If so, is it not less efficient performance wise than it&#x27;s &quot;counterpart&quot; isinstance() + properties comparison?<p>If this method is less efficient, it could be confusing, specially for newcomer.<p>Am I missing something.
评论 #23627353 未加载
fulafel将近 5 年前
The implicit isinstance the repurposing of the constructor syntax all seems very un-Pythonic.
vslira将近 5 年前
This is great. I&#x27;m currently trying to rewrite a heavily object-oriented library into a more functional one (the rewrite is necessary because of licensing issues, and functional because the original code is a clusterf*ck of mutation) and despite the whole company working on top of Python, I was seriously considering implementing it in SML[1] specifically due to pattern matching making the underlying algorithm of the main data structure incredibly easier to reason about and implement.<p>[1] Yes I know coconut-lang is a thing, but I didn&#x27;t want to introduce something that looks a lot like Python but isn&#x27;t in our codebase
loa_in_将近 5 年前
&gt;Note that because equality (__eq__) is used, and the equivalency between Booleans and the integers 0 and 1, there is no practical difference between the following two:<p>&gt;case True: ... case 1: ...<p>From practical perspective this is great, but I can imagine many cases where one could want to differentiate between those.<p>On one hand the number usually can be nested inside a structure and matching on == is more flexible. On the other hand matching on &#x27;is&#x27; is still letting users relax this behaviour and allows matching on type of primitives as well.
xiaodai将近 5 年前
This is trying to achieve a poor-human&#x27;s multiple-dispatch with match-case syntax
blondin将近 5 年前
finally our own switch statement and a modern and powerful one at that. we needed this a long time ago!
creativecupcak3将近 5 年前
Very excited about this! Looking forward to using these super switches when they are released.
macintux将近 5 年前
Pattern matching in Python is such a mess.<p>Python 3 eliminated the ability to match on tuples in function heads.<p>For loops can match on tuples, but lambda headers can’t.<p>As an Erlang fan, it’s maddening.
fnord77将近 5 年前
feels like languages are converging.