Something I love about Python is how the language managed to consistently evolve. I started with Python 1.6, and just loved how each version pushed me to try and adopt new practices. I remember decorators, str/bytes, format strings, async and typing as key improvements that changed the way I code today.
And for the same reasons, I am more and more afraid to see where all the duct tapes and layer over layer cake in Python is gonna taste is a few years. The language changed a lot even when focused on Python3 that the motto “There is only one way to do it” is meaningless. Already when working with numpy & pandas a lot, there is more than one sane way to do it and that will propagate to all Python ecosystem. On the other side of the coin, is that the language keeps growing and adapting. Let’s see where Python 4 lends in the future.
I have same feelings. Python is getting more complicated than it’s ever been. There are many ways to do a simple thing and it’s opposite of Python zen.
Just because a new feature is available doesn’t mean you have to use it.
Of course but someone, some day, will use it in a project you collaborate to and you will have to deal with it.
I’ve dug into this a bit more and I’m probably inclined to agree (I don’t use Python myself though).
However, the change does seem to be quite divisive, so it’s very possible this will just be used sparingly in most code bases.
It’s hard to limit this given the massive size of the Python ecosystem. One observation around this is how the new PEG parser is allowing language developments to be proposed and land very much quicker than before. There seems to have been a barrier to entry before which much of the community was accustomed to.
I’m personally neutral on this feature. But, I’d prefer that the whole ecosystem was considered during prioritisation rather than considering language features separately. I think they can be implemented independently, but from product perspective it doesn’t feel like the most important thing.
I don’t know about you, but I work in a team environment
My experience is more about being dropped in various projects where the lead and the team have already settled on what they accept or not and after being done, I was moving to the next one. So I tend to have less to say (if it is not critical).
I agree that in a team env on a project,it is easier to settle on what you accept or not as practice. I am a minority here.
From what I’ve read, the decision to add pattern matching seems to have been a fraught one. I’d imagine you would have plenty of allies in your team to argue against adopting the paradigm in your team’s code.
To be fair, I think Python has really embraced its position as the duct-tape language. It’s the language that lets you do anything from crafting custom packets to modelling neural nets. My experiences with it, in both corporate settings and ML usage, have been pretty subpar, but for folks who want to learn the language once and just learn domain specific duct tape to enter new subfields, it’s great.
TBH, in long term I feel that Python will act more as Graphql API to reach those numerous data and ML libraries so tightly linked to it from other languages. It is almost a gimmick to be able to call Python from your language of choice (Julia,Common Lisp,Go,etc.) for the purpose to access ML and Data libraries. IMHO, Python is not a good language to be treated as an API.
IMHO, Python is not a good language to be treated as an API.
IMHO, Python is not a good language to be treated as an API.
It’s not in my opinion but there really aren’t any other serious competitors for the sheer breadth of applications that Python provides that is also a nice, generatable API. Julia is a much more fun language for data science, but the libraries are still a lot more raw than Python, and folks still do use PyCall for stuff (e.g. there’s no good equivalent to something like spaCy). Nobody else has really “put their money where their mouth is”.
Absolutely amazing, I am almost ready to forgive Guido for the async mess :-)
Why is it so hard to supply a reasonable example in the article?
because it’s not an article, but a mailing list post for people with context?
Check out PEP 636 – Structural Pattern Matching: Tutorial.
While I had submitted this, I was seemingly the first to the draw on pattern matching in Python stories; it should probably be merged into the serious l4n7db.
This speaks out of my heart. I‘ve never missed pattern matching support in Python and it will probably lead to a lot of confusion down the road.
Pattern matching can be really powerful, but mixed with pythons general move away from functional programming (such as hiding away reduce in functools), it might very well turn out to be a double-edged sword.
You can move reduce but you can never take it away. All languages are going towards the same bag of features, gradual typing, GADTs, CTFE/Const expr, pattern matching.
Basically every language will crib from ML until ML is everywhere.
You also set the direction of Python and how it approaches functional programming and idioms. The functional language you want is already here.
The fact that we don’t need to use MacroPy to enable pattern matching is pretty nice. Python 3.10 feels like the 2.1/2.2 release did.
Wait, that’s the swtich-case from C.
As far as I know, that only deals with specific values. Python’s let you match on structure, with things like checking for isinstance, hasattr, len, and key in map. It also features guards.
key in map
Not quite, this could cause confusion: https://brennan.io/2021/02/09/so-python/
See the PEP for some examples: https://www.python.org/dev/peps/pep-0622/
It’s more like a rust’s match or an elixir’s case than a C’s switch.
Based off the title I was expecting something like in-language regexp like stuff. Indeed it looks like switch case support (but probably with more matching flexibility than C).
Python never ceases to amaze me. So complex in some ways, so simple in others.
Pattern matching is a well-known and pre-eminent feature in many other languages. In statically-typed languages it even has an exhaustivity check which tells you if you didn’t cover all cases. E.g. check out this function that implements fizzbuzz in OCaml:
let fizzbuzz n = match n mod 3, n mod 5 with
| 0, 0 -> "FizzBuzz"
| 0, _ -> "Fizz"
| _, 0 -> "Buzz"
It compiles with a warning (which can be set to error):
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a case that is not matched:
If you add a final case:
| _ -> string_of_int n
It compiles successfully. As it happens, when implementing fizzbuzz we need to handle the case where the number is not a multiple of 3 or 5. And the compiler catches that.
Would be cool if all these new types of patterns could also be used in places where we already have more primitive pattern matching (assignments / for loops) but couldnt find anything about that.
Does anyone know anything about that?
Indeed, in Haskell or OCaml, pattern matching is much more pervasive, and algebraic types make it much nicer to use. Still, even what they did in Python is quite useful in many cases. It’s not the first case of a dynamically typed language to do that either: Erlang has been doing it for a long time.
And Prolog before that.
This is nice. It actually adds some safety if you structure your code properly.