LWN: Comments on "Python structural pattern matching morphs again"

Python structural pattern matching morphs again

jezuch — Sat, 26 Dec 2020 19:55:08 +0000

> lifetimes. (...) Suggesting Rust, on the other hand, requires learning a new paradigm that affects pretty much every line of code.

To be fair, this is inferred most of the time (just like types and some other things); it's only needed (AFAICT, possibly wrongly) when you return a reference from a function which might also be one of the arguments. At least this was the moment it "clicked" for me and I learned to stop wondering WTH I need those annotations for and love lifetimes.

And besides, I think that many experienced programmers already know this "paradigm" without knowing it, so to speak.

Python structural pattern matching morphs again

mathstuf — Tue, 22 Dec 2020 21:43:18 +0000

To be fair, most of the app is slinging around HTTP requests to hosting providers (GraphQL/REST), parsing JSON, and forking off thousands of `git` processes :) . But the ability to just stick a `.par_iter()` in one place and get magic parallelism when running dozens of checks on dozens of commits (it's NxM) makes it amazingly easy. I could squeeze some more parallelism out of it with ticketed locks so that projects can be processed in parallel, but it hasn't been necessary to do that kind of stuff.

I've talked about the project before on here, but it all lives here for anyone curious:

https://gitlab.kitware.com/utils

All of the "rust" and "ghostflow" repositories; the "source-formatters" repo is relevant in that it's something we point our configurations at to do formatting verification and fixing. "git-import-third-party" is relevant for anyone wanting to use the "third party" check to make sure vendored code is not modified outside of dedicated patch tracking mechanisms.

Python structural pattern matching morphs again

mpr22 — Tue, 22 Dec 2020 17:27:48 +0000

> It's also performant enough that we just deploy the debug build

This is really cool, and I can't think of much higher praise for a language's performance :)

Python structural pattern matching morphs again

mathstuf — Tue, 22 Dec 2020 17:16:43 +0000

I think it depends heavily upon the kinds of code you're writing. I worked on a system in Rust that just could not go down (it manages/directs our development workflow). Rust's emphasis on error handling and consideration of what can go wrong means that if anything does go wrong, it goes to a log instead of crashing the program. There's very little lifetime usage in types throughout the 50k+ lines of code in it. They have allowed us to make the parts that need to be fast parallelisable without having to do manual checks of shared memory or the like.

This system has been running for over 4 years now, gained support for non-`master` default branches in July, updated its GraphQL schema usage in June, added a couple of small features this past spring, a few trickling in over time (as they do), and hasn't really had an "oh shit" moment in over a year (I've stopped scrolling the history; there have been 2 that I can remember that weren't "gitlab or github changed something on us" (those are just error logs, not crashes) and they were logic errors possible in any language). It's also performant enough that we just deploy the debug build so the backtraces are useful (when needed).

If you're crafting your own data structures, yes, Rust is going to be a tough sell over more convenient languages (though I argue that it is still worth it). But if you're writing code that needs to be correct in production, performance is of at least some note, and where threading can really help out there, Rust is definitely the top of my list for what to implement it in.

Python structural pattern matching morphs again

intgr — Tue, 22 Dec 2020 10:27:38 +0000

> 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.

Python structural pattern matching morphs again

intgr — Tue, 22 Dec 2020 10:08:24 +0000

I think the best feature of Rust is also the worst one: lifetimes. Suggesting to adopt a "classical" language such as Java or Go to a team not yet familiar to it isn't a huge jump.

Suggesting Rust, on the other hand, requires learning a new paradigm that affects pretty much every line of code. As good as that paradigm may be, it's a hard sell if the old paradigm works "well enough".

Python structural pattern matching morphs again

smitty_one_each — Wed, 16 Dec 2020 13:11:00 +0000

As far as I can tell, the thrust of this change is to move a bunch of logic into the type system.

This seems a trend in programming languages away from procedural and into more abstract mathematical realms.

The genius of Python is in striking a balance between "featuritis" and adding stuff for stuff's sake to the language and really hashing out the details that are going to matter in the long run.

Structural pattern matching seems an esoteric tool that one will gladly reach for when needed but mostly ignore in casual work.

Python structural pattern matching morphs again

papik — Thu, 10 Dec 2020 17:30:10 +0000

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

HelloWorld — Thu, 10 Dec 2020 12:32:25 +0000

Pattern matching isn't “some feature” that is “now fashionable”. It's a feature that has been around for 50 years at this point and has a solid mathematical foundation. It's frankly an embarrassment that Python still has to do without it to this day.

Python structural pattern matching morphs again

HelloWorld — Thu, 10 Dec 2020 12:26:32 +0000

What really bad features does rust have?

Python structural pattern matching morphs again

dbaker — Mon, 07 Dec 2020 17:51:08 +0000

> I cannot believe that somebody wrote those two words, by each other, unironically

I actually was trying to be a little snarky, I tend to think that Rust and Zig have some nice features, but also some really bad ones :)

Python structural pattern matching morphs again

iustin — Sun, 06 Dec 2020 20:47:56 +0000

Well, you could also say that the typing annotations are not enforce, so their usefulness is limited. But I've seen real bugs being found by the type annotations, so just because Python+pattern matching is not Haskell's one, I wouldn't say it's not useful.

At least least, it gives a more succint view on what the author of the code thought/how they saw the code flow should happen, (the same way as type annotations show what they thought of the involved types), so in my book they're very useful.

Python structural pattern matching morphs again

ehiggs — Sun, 06 Dec 2020 19:59:32 +0000

Python lacks the sum types that Haskell and Rust have which make the pattern matching exhaustive. So the usefulness appears to be quite limited.

Python structural pattern matching morphs again

iustin — Sat, 05 Dec 2020 21:35:09 +0000

> I write python pretty much all day. I'm excited to having this. maybe I'm the only one.

As a Haskell programmer in my free time who writes mostly Python at work, I'm very excited by this, and after all the typing annotations added to Python (which I just love), I'm quite surprised that a simple pattern matching results in "I don't want it in _my_ Python".

… but if Python doesn't add it, in one form or another, I think it's a loss for the Python language. Not for the community, since yes, it would raise the complexity of the language a tiny, tiny bit.

Python structural pattern matching morphs again

Deleted user 129183 — Fri, 04 Dec 2020 21:42:31 +0000

> sexy languages

I cannot believe that somebody wrote those two words, by each other, unironically.

> rust and zig have pattern matching

Oh, sure, those languages are fashionable right now, but in maybe, 15 years, they and their features will probably go out of fashion and style – just like, 15 years ago every language had to be object-oriented and have exceptions as the preferred method of the error handling, but apparently these things are now Evil, and new languages like Holy Rust do not have them or have them in a greatly reduced form – now procedural programming and result types are The Way.

But Python is a language that’s by now firmly established as one of the “major languages”, and we will probably still use it widely in 15 years (unless it goes the way of Perl/Raku). There’s no real reason to force some feature on it because it’s now fashionable, but when implemented badly, it could be an ugly legacy wart in the near future.

Python structural pattern matching morphs again

jezuch — Fri, 04 Dec 2020 09:12:50 +0000

It is much better if a feature is present in the language from the beginning, because then it is part of a consistent design. Adding a big feature like this to an established language risks making it a huge, inconsistent wart. And it looks to me to be the case with match statement in Python.

Mind you, exactly the same thing is happening in Java right now, where they are trying to extend the switch statement to support pattern matching. The issues are also almost identical. The difference is that in Java they envision it as part of a bigger picture - not just pattern matching, but turning the entire type system around to be more like algebraic types. (See for example the recent addition of Record types.) For this reason this is not a simple task and the work has been going on for a couple of years now. I like to read the discussions on their mailing list and, sorry to say that, the way it happens in Python looks terribly amateurish in comparison :) I'm actually in awe of the projects Valhalla and Amber members.

Python structural pattern matching morphs again

dbaker — Thu, 03 Dec 2020 18:20:15 +0000

Also, sexy languages like rust and zig have pattern matching. Frankly a lot of the arguments being made here could probably have been made about other functional elements like comprehensions, you can just write a loop or use filter() and map(), but a comprehension is a lot easier to use once you get the hang of it.

I write python pretty much all day. I'm excited to having this. maybe I'm the only one.

Python structural pattern matching morphs again

ms — Thu, 03 Dec 2020 17:55:19 +0000

> 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

nybble41 — Thu, 03 Dec 2020 17:32:14 +0000

> 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

NYKevin — Thu, 03 Dec 2020 17:29:39 +0000

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

mathstuf — Thu, 03 Dec 2020 17:12:27 +0000

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

rsidd — Thu, 03 Dec 2020 10:41:35 +0000

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

lxsameer — Thu, 03 Dec 2020 09:44:34 +0000

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

rsidd — Thu, 03 Dec 2020 09:17:15 +0000

This is not akin to the C switch statement as much as to the match construct in the ML family (eg ocaml). Immensely useful. There is something similar in Haskell, and it is implemented as a macro in Julia.

Python structural pattern matching morphs again

logang — Thu, 03 Dec 2020 01:58:27 +0000

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.