5 ms·
> How is case different from the elif pattern? Pattern matching is often conflated with switch-case by people who are unfamiliar, because pattern matching subs
by sullyj3 6y ago
> How is case different from the elif pattern?
Pattern matching is often conflated with switch-case by people who are unfamiliar, because pattern matching subsumes switch-case, but they're very much not the same thing. Structural pattern matching is much more powerful than checking a series of boolean conditions. It allows you to not only check the structure of a value, but bind parts of that structure to variables. It allows you to express logic that would would otherwise be fairly complex in a straightforward and transparent way.
- earthboundkid 6y ago> If the implementation is hard to explain, it's a bad idea. > If the implementation is easy to explain, it may be a good idea. Pattern matching is extremely complex, and for what?
- jsmeaton 6y agoAppealing to nothing but the zen of python is not an acceptable argument. Pattern matching is not (necessarily) extremely complex as it exists in a multitude of languages these days. Powerful does not automatically imply complex.
- earthboundkid 6y agoAcceptable to whom? Anyhow, read the PEP. It is an extremely complex new language feature.
- jsmeaton 6y agoTo many in the core team, for one. It’s a cutesy easter egg at best not a mission statement. I’ve read the pep. The nature of peps are complete by design. The concept is not overly complex especially since it exists in a number of other languages.
- otabdeveloper4 6y agoPython already has (limited) pattern matching. Example: for foo, (bar, baz) in nested_tuple_list: ... This works as expected. The current 3.10 implementation is just half-baked. They should have expanded the existing pattern matching facilities (added support for data structure destructuring). Presumably then you could just have used the existing walrus operator inside the already existing if-else constructs. That would have been the obvious path of least surprise. What we got instead seems inadequate.
- oblvious-earth 6y agoSo you would turn something like this: match command.split(): case ["north"] | ["go", "north"]: current_room = current_room.neighbor("north") case ["get", obj] | ["pick", "up", obj] | ["pick", obj, "up"]: ... # Code for picking up the given object In to this: if (["north"] | ["go", "north"] := command.split()): current_room = current_room.neighbor("north") elif (["get", obj] | ["pick", "up", obj] | ["pick", obj, "up"] := command.split()): ... # Code for picking up the given object And the walrus operator would assign to 0-many values as required? It kind of breaks it's current meaning and makes the lines very complex, I don't think this version would be more liked...
- otabdeveloper4 6y agoYes. The second version is "pythonic" and follows the principle of least surprise. The first version is certainly cleaner, but introduces, effectively, a new DSL sublanguage.
- oblvious-earth 6y agoThe second version also effectively introduces a new DSL sub-language, it just puts a walrus operator at the end of it. I agree the matching is complex, you only have to see what a portion of the grammar file it takes up: https://docs.python.org/3.10/reference/grammar.html https://docs.python.org/3.10/reference/grammar.html But embedding the match constructs inside existing Python symbols wouldn't reduce the amount of new grammar it would require.
- deleted 6y ago[deleted]
- brundolf 6y agoI would say it's much more powerful than switch-case, but it's only moderately more ergonomic than elif. The reason for the former being that switch-case only ever checks exact equivalency; if you need to do anything slightly more nuanced, you have to bail out to something more flexible.