7 ms·
Crimes with Python's Pattern Matching (2022)
- quotemstr 1y agoI've never understood why Python's pattern-matching isn't more general. First, "case foo.bar" is a value match, but "case foo" is a name capture. Python could have defined "case .foo" to mean "look up foo as a variable the normal way" with zero ambiguity, but chose not to. Second, there's no need to special-case some builtin types as matching whole values. You can write "case float(m): print(m)" and print the float that matched, but you can't write "case MyObject(obj): print(obj)" and print your object. Python could allow "..." or "None" or something in __match_args__ to mean "the whole object", but didn't.
- Aefiam 1y agocase .foo is explicitly mentioned in https://peps.python.org/pep-0622/ https://peps.python.org/pep-0622/ : > While potentially useful, it introduces strange-looking new syntax without making the pattern syntax any more expressive. Indeed, named constants can be made to work with the existing rules by converting them to Enum types, or enclosing them in their own namespace (considered by the authors to be one honking great idea)[...] If needed, the leading-dot rule (or a similar variant) could be added back later with no backward-compatibility issues. second: you can use case MyObject() as obj: print(obj)
- zahlman 1y agoI don't think I've written a match-case yet. Aside from not having a lot of use cases for it personally, I find that it's very strange-feeling syntax. It tries too hard to look right, with the consequence that it's sometimes quite hard to reason about.
- PokestarFan 1y agoI just use match case as a traditional switch statement.
- quotemstr 1y ago> > While potentially useful, it introduces strange-looking new syntax without making the pattern syntax any more expressive. Indeed, named constants can be made to work with the existing rules by converting them to Enum types, or enclosing them in their own namespace (considered by the authors to be one honking great idea)[...] Yeah, and I don't buy that for a microsecond. A leading dot is not "strange" syntax: it mirrors relative imports. There's no workaround because it lets you use variables the same way you use them in any other part of the language. Having to distort your program by adding namespaces that exist only to work around an artificial pattern matching limitation is a bug, not a feature. Also, it takes a lot of chutzpah for this PEP author to call a leading dot strange when his match/case introduces something that looks lexically like constructor invocation but is anything but. The "as" thing works with primitive too, so why do we need int(m)? Either get rid of the syntax or make it general. Don't hard-code support for half a dozen stdlib types for some reason and make it impossible for user code to do the equivalent. The Python pattern matching API is full of most stdlib antipatterns: * It's irregular: matching prohibits things that the shape of the feature would suggest are possible because the PEP authors couldn't personally see a specific use case for those things. (What's the deal with prohibiting multiple _ but allowing as many __ as you want?) * It privileges stdlib, as I mentioned above. Language features should not grant the standard library powers it doesn't extend to user code. * The syntax feels bolted on. I get trying to reduce parser complexity and tool breakage by making pattern matching look like object construction, but it isn't, and the false cognate thing confuses every single person who tries to read a Python program. They could have used := or some other new syntax, but didn't, probably because of the need to build "consensus" * The whole damn thing should have been an expression, like the if/then/else ternary, not a statement useless outside many lexical contexts in which one might want to make a decision. Why is it a statement? Probably because the PEP author didn't _personally_ have a need to pattern match in expression context. And look: you can justify any of these technical decisions. You can a way to justify anything you might want to do. The end result, however, is a language facility that feels more cumbersome than it should and is applicable to fewer places than one might think. Here's how to do it right: https://www.gnu.org/software/emacs/manual/html_node/elisp/pcase-Macro.html https://www.gnu.org/software/emacs/manual/html_node/elisp/pc... > If needed, the leading-dot rule (or a similar variant) could be added back later with no backward-compatibility issues. So what, after another decade of debate, consensus, and compromise, we'll end up with a .-prefix-rule but one that works only if the character after the dot is a lowercase letter that isn't a vowel. PEP: "We decided not to do this because inspection of real-life potential use cases showed that in vast majority of cases destructuring is related to an if condition. Also many of those are grouped in a series of exclusive choices." I find this philosophical stance off-putting. It's a good thing when users find ways to use your tools in ways you didn't imagine. PEP: In most other languages pattern matching is represented by an expression, not statement. But making it an expression would be inconsistent with other syntactic choices in Python. All decision making logic is expressed almost exclusively in statements, so we decided to not deviate from this. We've had conditional expressions for a long time.
- rpcope1 1y agoAfter doing Erlang and Scala pattern matching, the whole Python implementation just feels really ugly and gross. They should have cribbed a lot more of how Scala does it.
- orbisvicis 1y agoI've given up on matching as I'm tired of running into its limitations. That said, I don't think OP's antics are a crime. That SyntaxError though, that might be a crime. And a class-generating callable class would get around Python caching the results of __subclasshook__.
- hwayne 1y agoNow I'm mad I didn't remember the word "antics". It's so much more evocative than "crimes"!
- techlatest_net 1y ago[dead]
- vlade11115 1y agoWhile the article is very entertaining, I'm not a fan of the pattern matching in Python. I wish for some linter rule that can forbid the usage of pattern matching.
- siddboots 1y agoCan you explain why? Genuinely curious as a lover of case/match. My only complaint is that it is not general enough.
- kurtis_reed 1y agoDouble indentation
- maleldil 1y agoSo? Other languages with pattern match similarly have such double indentation. C-style switch with unintended cases is weird.
- smcl 1y agoIf you're experienced enough with Python to say "I want to eliminate pattern matching from my codebase" you can surely construct that as a pre-commit check, no?
- jbmchuck 1y agoShould be easily doable with a semgrep rule, e.g.: ~> cat semgrep.yaml rules: - id: no-pattern-matching pattern: | match ...: message: | I'm not a fan of the pattern matching in Python severity: ERROR languages: - python ... ~> cat test.py #!/usr/bin/env python3 foo = 1 match foo: case 1: print("one") ... ~> semgrep --config semgrep.yaml test.py no-pattern-matching I'm not a fan of the pattern matching in Python 4┆ match foo: 5┆ case 1: 6┆ print("one") (exits non-0)
- purplehat_ 1y agoCould someone explain just what's so bad about this? My best guess is that it adds complexity and makes code harder to read in a goto-style way where you can't reason locally about local things, but it feels like the author has a much more negative view ("crimes", "god no", "dark beating heart", the elmo gif).
- gnulinux 1y agoSide effects
- taeric 1y agoI took the memes as largely for comedic effect, only? I do think there is a ton of indirection going on in the code that I would not immediately think to look for. As the post stated, could be a good reason for this in some things. But it would be the opposite of aiming for boring code, at that point.
- xg15 1y agoMaybe I have too much of a "strongly typed language" view here, but I understood the utility of isinstance() as verifying that an object is, well, an instance of that class - so that subsequent code can safely interact with that object, call class-specific methods, rely on class-specific invariants, etc. This also makes life directly easier for me as a programmer, because I know in what code files I have to look to understand the behavior of that object. Even linters use it to that purpose, e.g. resolving call sites by looking at the last isinstance() statement to determine the type. __subclasshook__ puts this at risk by letting a class lie about its instances. As an example, consider this class: class Everything(ABC): @classmethod def __subclasshook__(cls, C): return True def foo(self): ... You can now write code like this: if isinstance(x, Everything): x.foo() A linter would pass this code without warnings, because it assumes that the if block is only entered if x is in fact an instance of Everything and therefore has the foo() method. But what really happens is that the block is entered for any kind of object, and objects that don't happen to have a foo() method will throw an exception.
- cauthon 1y ago
- pansa2 1y agoThe real crime is the design of Python's pattern matching in the first place: match status: case 404: return "Not found" not_found = 404 match status: case not_found: return "Not found" Everywhere else in the language, you can give a constant a name without changing the code's behaviour. But in this case, the two snippets are very different: the first checks for equality (`status == 404`) and the second performs an assignment (`not_found = status`). https://x.com/brandon_rhodes/status/1360226108399099909 https://x.com/brandon_rhodes/status/1360226108399099909
- quotemstr 1y agoAnd there was a much better proposal that got rejected in favor of what we got: https://peps.python.org/pep-0642/ https://peps.python.org/pep-0642/
- danudey 1y agoThe very first example there shows a match/case block where almost every single case just runs "pass" and yet every single one has a side effect. It's very difficult to read at first, difficult to understand if you're new to the syntax, and is built entirely around side effects. This might be one of the worst PEPs I've ever seen just based on that example alone. Fun fact: you can do the same thing with the current match/case, except that you have to put your logic in the body of the case so that it's obvious what's happening.
- deleted 1y ago[deleted]
- almostgotcaught 1y agobecause it's not a `switch` it's a `match` ie pattern matching...
- pansa2 1y agoDoesn't matter what it is, it shouldn't break fundamental rules of the language. Ruby's `case`/`in` has the same problem.
- Y_Y 1y agoBarely a misdemeanor, all of the typechecks were deterministic
- danudey 1y agoNext step is to have the subclass check pack all the code up, send it to ChatGPT, ask it if it thinks subjectively that class A should be a subclass of class B, and then run sentiment analysis on the resulting text to make the determination.
- charlieyu1 1y agoMore and more dubious things were designed in Python these days. A recent PEP purposes to use {/} as the empty set
- umgefahren 1y agoIdk that doesn’t sound so dubious to me. ∅ might be more approachable for the PHDs then set() ;)
- rtrgrd 1y agowe all love non ascii code (cough emoji variable names)
- augusto-moura 1y agoProblem is, we already have a syntax for empty lists [], empty tuples (), and {} is taken for an empty dict. So having a syntax for an empty set actually makes sense to me
- kurtis_reed 1y ago{:} should have been the empty dict, now there's no good solution
- augusto-moura 1y agoI agree that {:} would be a better empty expression for dicts, but that ship has already sailed. {/} looks like a good enough alternative
- sitkack 1y agoThere is a way to make it work. Python has no problem breaking things across major versions.
- 1y ago
- btown 1y agoMy favorite Python "crime" is that a class that defines __rrshift__, instantiated and used as a right-hand-side, lets you have a pipe operator, regardless of the left-hand-side (as long as it doesn't define __rshift__). It's reasonably type-safe, and there's no need to "close" your chain - every outputted value as you write the chain can have a primitive type. x = Model.objects.all() >> by_pk >> call(dict.values) >> to_list >> get('name') >> _map(str.title) >> log_debug >> to_json It shines in notebooks and live coding, where you might want to type stream-of-thought in the same order of operations that you want to take place. Need to log where something might be going wrong? Tee it like you're on a command line! Idiomatic? Absolutely not. Something to push to production? Not unless you like being stabbed with pitchforks. Actually useful for prototyping? 1000%.
- divbzero 1y agoI suppose you could use the same trick with __ror__ and | (as long as the left-hand side doesn’t define __or__). x = Model.objects.all() | by_pk | call(dict.values) | to_list | get('name') | _map(str.title) | log_debug | to_json
- btown 1y agoSadly many things define the __or__ operator, including dicts and sets which are common to find in pipelines. (https://peps.python.org/pep-0584/ https://peps.python.org/pep-0584/ was a happy day for everyone but me!) In practice, rshift gives a lot more flexibility! And you’d rarely chain after a numeric value.
- mananaysiempre 1y agoIt’s still useful in related situations. The following crime often finds its way into my $PYTHONSTARTUP: class more: def __ror__(self, other): import pydoc pydoc.pager(str(other)) more = more() and here the low precedence of | is useful.
- ck45 1y agoOr overloading division like https://scapy.net/ https://scapy.net/
- thayne 1y agoI don't think this is necessarily a "crime", I could see this being useful. An example that uses a similar approach would be if you had a metaclass that overrode __instancecheck__ to return true if a string matched a regular expression. Then you could create (dynamically defined) classes that used that metaclass to use in match statements to march a string against multiple regexes. Unfortunately, I can't think of a good way to extract any capture groups.
- VagabundoP 1y agook, took me a bit to wrap my head around whats going on here, but actually this is neat, and probably useful. Ive been hobbying in python for a decade plus at this point and it still ties my brain in knots sometimes with how it works at runtime. I do enjoy working with it though. E: just to clarify if you're going to use this don't bury it deep in a multi file code structure, explicitly have it in the same file as you use it, otherwise people will get confused.
- M0r13n 1y agoPersonally, I have never liked the PEP 634 pattern matching. I write a lot of code in Python. 99% of the time when I could use pattern matching, I am going to use simple if statements or dictionaries. Most of the time, they are more straightforward and easier to read, especially for developers who are more familiar with traditional control flow.
- NeutralForest 1y agoYou should use if statements if that's what you need. The match statement is for structural pattern matching mostly.
- Q6T46nT668w6i3m 1y agoWhat’s the problem using it as a switch statement if you care about typographic issues? I do this so I’d like to know if I missed something and this is a bad practice.
- NeutralForest 1y agoIt's not an issue, but that's not where most of the power is and can also be confusing since if you use variables in the case statement, the way it watches does not behave like a simple switch.
- Balinares 1y agoDictionaries with a limited key and value type definition are fine, but dictionaries as a blind storage type are a recipe for crashing in prod with type errors or key errors. Structural pattern matching exists to support type safety. I'll argue that code is in fact not easy to read if reading it doesn't tell you what type an item is and what a given line of code using it even does at runtime.
- odyssey7 1y agoHaving user other languages after finishing university studies, Python does not spark joy.
- JohnKemeny 1y agoDiscussed 3 years ago: Crimes with Python's pattern matching 406 points on Aug 2, 2022. 120 comments https://news.ycombinator.com/item?id=32314368 https://news.ycombinator.com/item?id=32314368
- TeeMassive 1y agoI've been doing Python full time for about 4 years now. I always found that when pattern matching is used it always ends up increasing the cognitive load significantly. It shines for simple cases, and for precise object pattern sniping. But anything that acts on nested objects or more than 3 members with multiple case statements is pre-programmed for failure. What makes it worse, is that there seems to be a trend where other Python adepts will default to pattern matching over everything else, like a too good of a hammer.