Python structural pattern matching morphs again

Posted Dec 3, 2020 18:20 UTC (Thu) by dbaker (guest, #89236)
In reply to: Python structural pattern matching morphs again by rsidd
Parent article: Python structural pattern matching morphs again

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

Posted Dec 4, 2020 9:12 UTC (Fri) by jezuch (subscriber, #52988) [Link]

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

Posted Dec 4, 2020 21:42 UTC (Fri) by Deleted user 129183 (guest, #129183) [Link] (8 responses)

> 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

Posted Dec 7, 2020 17:51 UTC (Mon) by dbaker (guest, #89236) [Link] (6 responses)

> 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

Posted Dec 10, 2020 12:26 UTC (Thu) by HelloWorld (guest, #56129) [Link] (5 responses)

What really bad features does rust have?

Python structural pattern matching morphs again

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

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

Posted Dec 22, 2020 17:16 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

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

Posted Dec 22, 2020 17:27 UTC (Tue) by mpr22 (subscriber, #60784) [Link] (1 responses)

> 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

Posted Dec 22, 2020 21:43 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

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

Posted Dec 26, 2020 19:55 UTC (Sat) by jezuch (subscriber, #52988) [Link]

> 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

Posted Dec 10, 2020 12:32 UTC (Thu) by HelloWorld (guest, #56129) [Link]

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

Posted Dec 5, 2020 21:35 UTC (Sat) by iustin (subscriber, #102433) [Link] (3 responses)

> 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

Posted Dec 6, 2020 19:59 UTC (Sun) by ehiggs (subscriber, #90713) [Link] (1 responses)

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

Posted Dec 6, 2020 20:47 UTC (Sun) by iustin (subscriber, #102433) [Link]

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

Posted Dec 16, 2020 13:11 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link]

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.