Python structural pattern matching morphs again

Posted Dec 3, 2020 1:58 UTC (Thu) by logang (subscriber, #127618)
Parent article: Python structural pattern matching morphs again

IMO the match proposal is counter to almost half of the zen of python. Specifically these ideals:

> Explicit is better than implicit.
> Simple is better than complex.
> Flat is better than nested.
> Readability counts.
> Special cases aren't special enough to break the rules.
> There should be one-- and preferably only one --obvious way to do it.
> Although never is often better than *right* now.
> If the implementation is hard to explain, it's a bad idea.

Not to mention python tends to prefer duck typing a lot and most of the examples are counter to that.

If accepted, I'd almost certainly ask my colleagues not to use it and suggest traditional methods during review.

Python structural pattern matching morphs again

Posted Dec 3, 2020 9:44 UTC (Thu) by lxsameer (guest, #65438) [Link] (2 responses)

Totally agree, The rational behind it doesn't make sense either, In order to utilize pattern matching a language has to have a better type system than what Python has at the moment and beside that they're trying to address some issues that Protocols/Traits are better solutions.

To me, it seems that because pattern matching and type systems are a trend in past few years they want them in Python otherwise it's violates Python's Zen and would be mess.

Python structural pattern matching morphs again

Posted Dec 3, 2020 10:41 UTC (Thu) by rsidd (subscriber, #2582) [Link] (1 responses)

Yes, a recent trend if by "last few years" you mean "since the 1970s" (ML). Python has lifted several things from functional languages. This is another and is extremely useful. Those languages largely use flexible (polymorphic / inferred) types too.

Python structural pattern matching morphs again

Posted Dec 3, 2020 17:32 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> Those languages largely use flexible (polymorphic / inferred) types too.

Inferred static types are very different from dynamic types, even if they appear superficially similar at the source level. Even with polymorphism, the type of the value being matched must be known in advance for each particular instance. The compiler can use this information to generate jump tables rather than long if/else chains and to statically test for exhaustiveness in the match patterns. The simplest pattern matches (e.g. destructuring a product type) can be optimized out altogether.

You can get approximately the same behavior with runtime tests in dynamic languages, but the performance cost is considerable.

Python structural pattern matching morphs again

Posted Dec 3, 2020 17:12 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

Not to mention python tends to prefer duck typing a lot and most of the examples are counter to that.

Agreed. If it allowed something like this, I think it'd be way more powerful:

match ptlike:
    case c(x=x, y=y):
        return Point3d(x, y, 0)

to match on *any* class with an x and y attribute (rather than `hasattr` checks or an `AttributeError` catch)? But maybe the AttributeError is just more Pythonic anyways… This makes me think…is the "in front of parens" token *always* looked up in the scope and not allowed to be a captured variable? If so, it's kind of odd that even it gets to be special too…

Python structural pattern matching morphs again

Posted Dec 3, 2020 17:29 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

Python does not meaningfully distinguish between class instantiation and function calls. If you allow destructuring the function call operator, where does it end? Would we have case x + y: print(x, y)?

IMHO this whole thing would make a lot more sense if it *just* supported the regular unpacking syntax a la PEP 448, and (maybe) a very conservative extension for matching simple enum constants. Everything else is just going to require too many weird special cases to get right.

Python structural pattern matching morphs again

Posted Dec 3, 2020 17:55 UTC (Thu) by ms (subscriber, #41272) [Link]

> where does it end? Would we have case x + y: print(x, y)?

Haskell has n+k patterns (albeit behind an option - they're off by default), though one of the args must be a literal constant. But, err, I suspect Prolog and the halting-problem in general is where it would end if you took this to its logical conclusion.

Python structural pattern matching morphs again

Posted Dec 10, 2020 17:30 UTC (Thu) by papik (guest, #15175) [Link]

I was thinking... Python already has an assign-ish keyword "as". Maybe it is more pythonic something like:

match ptlike:
    as Point2d(x, y):
        return Point3d(x, y, 0)

But in my opinion there are too many colons...

Python structural pattern matching morphs again

Posted Dec 22, 2020 10:27 UTC (Tue) by intgr (subscriber, #39733) [Link]

> Not to mention python tends to prefer duck typing a lot and most of the examples are counter to that.

I've seen lots of backpedalling on that approach. It's been a slow transition, but starting with the introduction of Abstract Base Classes (ABC), and more importantly, type hints, the whole community has become more accepting of nominative typing.

Data types that used to be hidden as internal implementation details are more frequently being exposed as public types, etc.

It would be possible to achieve "duck typing" type hints with protocols (structural typing) as well, but ironically the current implementation in Python is problematic.