I use Python on an almost daily basis professionally and it has enabled me and my peers to get up and running with software remarkably quickly, but it seems that with every bigger release of Python there is syntax added to the language and I’m honestly curious as to what the amount of outcry has to be for something like structural pattern matching to be added. It must be a non-trivial amount of work to add this and maintain it for years to come, so was the amount of requests to support this non-trivial as well?
Contrasting with a language like Go, which I’ve not used all that much, it seems like the maintainers deliberately eschew many niceties people have come to expect from Python just so the language as a whole is neater with fewer ways to do things. I’m not trying to shit on Python in any respect, I guess I just haven’t come into contact with reasons why any syntactical additions are still being made. To me, just because you can add new language constructs doesn’t mean you necessarily should; that’s what the underlying motivation and rationale PEP 635 essentially comes off as.
I think what happens is that many Python developers are polyglots, see “good ideas” from other languages, and try to think of ways to incorporate it into Python.
Structural pattern matching has always been a bit of a “magical feature from those other languages”, but I think that Rust and Scala really paved the way for proving the utility in very imperative code. And it works alright as a way for Python to finally get a switch statement.
And to really go to bat for the Python developers… for every feature like this we get 5 or 10 things like “Now you can write T | V instead of typing.Union[T, V]”, or new_dictionary = {**old_dictionary, "extra_key": 1}, or merged_dictionary = dict_1 | dict_2.
There’s lots of discourse around the “harder” feature additions, because so many of the other feature additions are, to be frank, no brainers. Just clear wins for everyone involved, things that do “what you expect”. Dictionaries preserving insertion order happened only fairly recently!
The sort of summit of expressivity has not been reached in any language in my opinion, and Python is, I think, a very positive contributor to this design space.
Which is a bad combination. 99% of Python developers will never use this, so when they are looking at piece of code that does use it, they’re going to scratch their head and ask “wait, how does this work?”
for/else used to be the poster-child for infrequently used, often confused Python features, and probably it is still the worst offender, but I don’t think the language needs more competitors in the space.
By comparison, f-strings (which I was skeptical of) are useful more or less everywhere, so everyone who isn’t a novice will have used them and know more or less how they work (minus understanding the edge cases around brackets inside an f-string).
Here’s a quiz. What does this do?
def f(*, arg1):
pass
f()
This feature is sort of borderline to me, but I’m curious if it’s more or less obvious than I think.
For me pattern matching feels Pythonic, mostly because it’s already idiomatic to use destructuring in a bunch of other places, like in assignments and looping constructs. So it felt like an odd gap that you couldn’t use destructuring in conditionals (a previous comment of mine with some examples). But there are a bunch of edge cases in this new feature so I’m not 100% sure how much I’ll use it in practice.
This feature is sort of borderline to me, but I’m curious if it’s more or less obvious than I think.
This blows up because parameters after * are keyword only. You have to pass, e.g., f(arg1="foo"). (Full disclosure, I guessed the right answer, but I definitely had to check the docs to be sure.)
I’m not sure if this is your point, but for me this is a great example of Python providing (way) too many knobs and dials.
I feel like if you showed ~any programmer the switch statement they would be able to say what’s going on. Fancy if statements that look like how you write out case analysis for function definitions in math.
There are definitely foot guns! But “non-intuitive” feels off to me. I think it would be interesting to do some real polling on Python programmers for “normal usage”. Like the text adventure seems straightforward to me, and way better than the “first we do a length check then destructure” flow
stuff like default arguments being a function property so being a shared reference or … almost every syntactic async thing has a lot higher “this doesn’t do what I thought it does” ratio IMO. And kwarg-only parameters are pretty useful! Subjective though!
to be honest I was also under the impresison that the binding rules were confusing (mostly from reading examples from people who were arguing it was confusing). But going through the PEP tutorial above all the code was straightforward for me and also expressed patterns for things that I find extremely awkward in Python.
I think the biggest gotcha is around constants, since a bare name is always a capture pattern, but dotted name access is allowed. tbh I feel like there should have just been an “Escape symbol” to resolve this question…. but I think that fortunately this is a very easy lint (one that’s present in … every pattern match-included language). It’s not perfect, but I think in practice things will work out through osmosis.
I genuinely did not know for/else was in the language. I’m kind of glad because I’ve used better-suited data structures and programming style because of it, but, wow.
I’ve been writing Python as my go-to language since late 90s and just love how the language has evolved and how the rollout of new features influenced my style and way of thinking. Decorators, generators, comprehensions, context and type annotations all had a major impact on the way I design and write code. I very much like Go’s simplicity, but I find that Python and it’s community has managed to strike a good balance between simplicity (but not minimalism) and progress and keep the language evolving. Ruby’s evolution, for instance, looks a bit sad in comparison. JavaScript, for one, was a surprising success, where the new features really made the language more flowing and expressive, in particular the arrow functions and restructuring.
I use Python on an almost daily basis professionally and it has enabled me and my peers to get up and running with software remarkably quickly, but it seems that with every bigger release of Python there is syntax added to the language and I’m honestly curious as to what the amount of outcry has to be for something like structural pattern matching to be added. It must be a non-trivial amount of work to add this and maintain it for years to come, so was the amount of requests to support this non-trivial as well?
Contrasting with a language like Go, which I’ve not used all that much, it seems like the maintainers deliberately eschew many niceties people have come to expect from Python just so the language as a whole is neater with fewer ways to do things. I’m not trying to shit on Python in any respect, I guess I just haven’t come into contact with reasons why any syntactical additions are still being made. To me, just because you can add new language constructs doesn’t mean you necessarily should; that’s what the underlying motivation and rationale PEP 635 essentially comes off as.
I think what happens is that many Python developers are polyglots, see “good ideas” from other languages, and try to think of ways to incorporate it into Python.
Structural pattern matching has always been a bit of a “magical feature from those other languages”, but I think that Rust and Scala really paved the way for proving the utility in very imperative code. And it works alright as a way for Python to finally get a
switchstatement.And to really go to bat for the Python developers… for every feature like this we get 5 or 10 things like “Now you can write
T | Vinstead oftyping.Union[T, V]”, ornew_dictionary = {**old_dictionary, "extra_key": 1}, ormerged_dictionary = dict_1 | dict_2.There’s lots of discourse around the “harder” feature additions, because so many of the other feature additions are, to be frank, no brainers. Just clear wins for everyone involved, things that do “what you expect”. Dictionaries preserving insertion order happened only fairly recently!
The sort of summit of expressivity has not been reached in any language in my opinion, and Python is, I think, a very positive contributor to this design space.
I just feel like this particular addition is
A) Not applicable in a lot of codebases
B) Not super-intuitive
Which is a bad combination. 99% of Python developers will never use this, so when they are looking at piece of code that does use it, they’re going to scratch their head and ask “wait, how does this work?”
for/elseused to be the poster-child for infrequently used, often confused Python features, and probably it is still the worst offender, but I don’t think the language needs more competitors in the space.By comparison, f-strings (which I was skeptical of) are useful more or less everywhere, so everyone who isn’t a novice will have used them and know more or less how they work (minus understanding the edge cases around brackets inside an f-string).
Here’s a quiz. What does this do?
This feature is sort of borderline to me, but I’m curious if it’s more or less obvious than I think.
For me pattern matching feels Pythonic, mostly because it’s already idiomatic to use destructuring in a bunch of other places, like in assignments and looping constructs. So it felt like an odd gap that you couldn’t use destructuring in conditionals (a previous comment of mine with some examples). But there are a bunch of edge cases in this new feature so I’m not 100% sure how much I’ll use it in practice.
This blows up because parameters after
*are keyword only. You have to pass, e.g.,f(arg1="foo"). (Full disclosure, I guessed the right answer, but I definitely had to check the docs to be sure.)I’m not sure if this is your point, but for me this is a great example of Python providing (way) too many knobs and dials.
I feel like if you showed ~any programmer the switch statement they would be able to say what’s going on. Fancy if statements that look like how you write out case analysis for function definitions in math.
There are definitely foot guns! But “non-intuitive” feels off to me. I think it would be interesting to do some real polling on Python programmers for “normal usage”. Like the text adventure seems straightforward to me, and way better than the “first we do a length check then destructure” flow
stuff like default arguments being a function property so being a shared reference or … almost every syntactic async thing has a lot higher “this doesn’t do what I thought it does” ratio IMO. And kwarg-only parameters are pretty useful! Subjective though!
I dunno, seems unclear to me when using a name declares a variable vs when it describes a pattern. But maybe I’m overthinking it.
to be honest I was also under the impresison that the binding rules were confusing (mostly from reading examples from people who were arguing it was confusing). But going through the PEP tutorial above all the code was straightforward for me and also expressed patterns for things that I find extremely awkward in Python.
I think the biggest gotcha is around constants, since a bare name is always a capture pattern, but dotted name access is allowed. tbh I feel like there should have just been an “Escape symbol” to resolve this question…. but I think that fortunately this is a very easy lint (one that’s present in … every pattern match-included language). It’s not perfect, but I think in practice things will work out through osmosis.
I genuinely did not know for/else was in the language. I’m kind of glad because I’ve used better-suited data structures and programming style because of it, but, wow.
I’ve been writing Python as my go-to language since late 90s and just love how the language has evolved and how the rollout of new features influenced my style and way of thinking. Decorators, generators, comprehensions, context and type annotations all had a major impact on the way I design and write code. I very much like Go’s simplicity, but I find that Python and it’s community has managed to strike a good balance between simplicity (but not minimalism) and progress and keep the language evolving. Ruby’s evolution, for instance, looks a bit sad in comparison. JavaScript, for one, was a surprising success, where the new features really made the language more flowing and expressive, in particular the arrow functions and restructuring.
Good stuff! Looks better compared to shitty :=