9 ms·

Python 3.10.0a6 is available, now with 100% more pattern matching

125 points by pansa2 6y ago

vletal 6y ago
Exciting! Especially I like the named attribute matching [1] and dict matching [2]. Scala does not have that. If you have a case (data) class with 13 parameters, you need to match on all of them, instead of doing `MyClass(param=value)`. Similarly you can not easily pattern match on `Map` (`dict`). One thing which I am missing though is matching on f-strings. Such a powerful feature in Scala. [1] https://www.python.org/dev/peps/pep-0636/#adding-a-ui-matching-objects https://www.python.org/dev/peps/pep-0636/#adding-a-ui-matchi... [2] https://www.python.org/dev/peps/pep-0636/#going-to-the-cloud-mappings https://www.python.org/dev/peps/pep-0636/#going-to-the-cloud...
- 0x008 6y ago
  I don’t understand what you are saying? In scala you do not have to match on all parameters. You can use the underscore operator to skip the other attributes. Also you can match a map since every map is just a sequence of Tuples in scala. However why would you ever do this? It is really impractical for large sequences and if I have only a very limited number of attributes I would not use a map I guess.
  - tomsmeding 6y ago
    > You can use the underscore operator to skip the other attributes And have to add an underscore in the right position when you ever add an attribute? With partial matching like described, you don't have to change the pattern when adding fields to the data structure. I guess the GP was referring to this.
    - 0x008 6y ago
      Well that is a little bit different I guess. You probably could do some unapply shenanigans to achieve the same result but that off the top of my head I would not know how to do that.
  - vletal 6y ago
    Well sure, wildcards still count as matching. The ability to use named params instead could clean some codebases a bit. Also I get that there are reasons for the Map matching not being present in Scala. All I am saying is that it's cool that it's in python.
- dividedbyzero 6y ago
  You can use guards to achieve a lesser version of this in Scala, e.g.: case x:YourCaseClass if(x.oneField=="value") => ...
tus89 6y ago
This is nice and all, but part of me feels like having code structured around the shape of tuples returned by functions has an element of pattern-smell (and by pattern I mean design pattern).
- _ZeD_ 6y ago
  If this can make feel better, you can type-alias the tuple shape and "squint" them as classes
- coldtea 6y ago
  >having code structured around the shape of tuples returned by functions has an element of pattern-smell (and by pattern I mean design pattern). This is a near content-less critique, which amounts to: "shaping code around what's returned by functions looks like a design pattern (and implied: design patterns are bad)" Well, design patterns are neither bad, nor good. They are what they are: a high level description of common solutions to common problems. By themselves design patterns are not problems or problematic. It's applying them where they don't fit the problem - or where something simpler will suffice - that's problematic (common e.g. to J2EE era Java). Some also say that design problems point to a language deficiency (that is, make up for a lack of language feature, like e.g. closures or dynamic typing). If we accept the above folk wisdom, built-in pattern matching would be the exact opposite of what you say. It wouldn't be a "design pattern smell" but rather a first-class feature that frees you from having to workaround its lack with design patterns. But I'd go further and say that the complain is nonsensical anyway. What exactly does "having code structured around the shape of tuples returned by function" even mean? If there's a need to extract values from the results of a function (e.g. in a parser, a protocol handler, etc.) then we don't have alternatives, we will structure our code "around the shapes returned". The question if whether we will do it through ad-hoc solutions (like chained "if" statements, a series of switch/case, etc.), through some convoluted design pattern like a Visitor, or by first class support for exactly our need. This first class support is exactly what pattern matching syntax offers. And far from being some smell/Python novelty, it's an old staple found in Haskell, ML, Ocaml, Lisp, and several other places besides...
  - 6y ago
guram11 6y ago
While I embrace this feature something about using "equal/assignment" bothers me, I prefer "as" binding in "with" statement style case Point as (0, y):
- quietbritishjim 6y ago
  That doesn't resolve (at least not obviously to me) the ambiguity where you want to match a Point where the first value is equal to the existing variable x, while the second value is anything and you want to capture it in a new variable y. I prefer the suggestion that appeared at one point where captured variables would have to be suffixed with ?, like this: case Point(x, y?): For those not aware, the solution today is that x must contain a . in its name by virtue of being a member of an object or an imported module: case Point(something.x, y):
  - coldtea 6y ago
    >the solution today is that x must contain a . in its name A crappy solution, if I ever saw one...
  - pkolaczk 6y ago
    case Point(x, y) if x == something Where's the problem?
    - quietbritishjim 6y ago
      Syntax cleanliness is ultimately subjective, so if you don't see a problem with that then I don't think I can persuade you. To me, it just seems obvious that it's more painful than what I wrote. But I'll mention a couple of specific reasons anyway: * The most concerning thing is knowing to write that in the first place. I think that if the ? syntax were the real one then you'd soon get used to writing a snippet like in my comment, but with the current syntax it's always going to take a bit of mental mind bending to come up with what you've written. * Even if you get it right when writing it, what you've written is vastly more verbose, and adding that redundant variable name (twice!) is just going to be distracting when reading it back. By the way, what you wrote is not equivalent to what I wrote (I wonder if that means your snippet is not as obvious as you're suggesting): you've matched against "something" rather than "x". Instead you'd need to do: case Point(also_x, y) if also_x == x:
Uzomidy 6y ago
It's not 100% more — 100% would be twice as much. In this case, we've gone from none at all to having some, which is infinitely more.
- DemocracyFTW 6y ago
  Came here to say that, am satisfied. It was twice as cold on Monday than it was on Sunday. /duck
  - teekert 6y ago
    If you'd use Kelvin I'd be ok with your remark, although I'd be wondering on what planet you live.
    - kubanczyk 6y ago
      My guess it was just at Moon's terminator. (Parent didn't say "planet".) Can quickly go from 300 K to 150 K, source https://ars.els-cdn.com/content/image/1-s2.0-S0019103516304869-gr5.jpg https://ars.els-cdn.com/content/image/1-s2.0-S00191035163048...
- ghego1 6y ago
  Thanks for the clarification! I am relatively new to python and I thought that I had not noticed this feature :-D
- tpoacher 6y ago
  and don't get me started on "biweekly"
  - OJFord 6y ago
    That really is a weird one, because here in the UK we say 'fortnightly' (for 'every other week'); so 'biweekly' would definitely be taken to mean 'twice per week'. That also matches 'biannual' (an event that occurs every other year is 'biennial'), so 'biweekly' as 'fortnightly' is certainly to be proscribed, in my book.
a-dub 6y ago
does this mean that python has graduated from lisp without parens to ml without 'let'? (less 'fun' ml?)
- bjoli 6y ago
  Why do would you say python is like a lisp without parens? Common lisp is warty, battle tested and productive - but the similarities end there. I tried to use Hy, but even with the most glaring difference mitigated, python felt nothing like lisp. I was still writing very much python.
  - a-dub 6y ago
    map, reduce, filter, lambda, etc sure, no car, cdr or cons, but you can do that with list notation and it's cleaner anyhow.
    - smitty1e 6y ago
      > map, reduce, filter, lambda, etc Those are generally functional, not lisp-specific, concepts.
      - a-dub 6y ago
        ...aaand the first language to define them was...
        pjmlp 6y ago
        Lambda calculus.
        bjoli 6y ago
        probably APL, like all these things. It was probably used in some fashion before that, but my experience that is where it was named and standardised. Heck, it is even mapped to an ASCII character IIRC: \ or /. Can't remember which, and on GPRS so Google takes a good 2 minutes.
bluefox 6y ago
Can't wait to make my programs incompatible with all previous versions!
- smitty1e 6y ago
  "What do you mean it crashed? Just upgrade everything to the latest version."
- nickjj 6y ago
  Fortunately we have tools like Docker and to a lesser extent Python Virtual Environments to help deal with this in a sane way. But yeah for 1 off zero dependency Python scripts I won't be using the new features until major distros ship with 3.10 by default. Part of the appeal to me of Python is most distros and operating systems have it installed by default. Being able to curl down a single file and run it is really nice. For that to work requires using a version of Python that most folks have by default. That means coding against 3.6's features (at least we can use f-strings now!).
  - Already__Taken 6y ago
    I haven't found this much use because you still can't assume the default version really and pip seems to be broken all the time by default.
- singularity2001 6y ago
  In utopia every new version would come with a tool to convert new code to old code (for all those non-nightly systems). ideally even with file extensions: .py3 runs on all python3 versions .py38 runs on all python3.9 versions and above
  - aflag 6y ago
    That's not really enough as you depend on libraries you don't own. All the sudden in order to update a small library you use you need to update to a new version of Python. So, yeah, new syntax is always disruptive. My utopia has new syntax being added very seldomly with loads of notice period and a `from __future__ import newsyntax` phase before the syntax is considered "production ready". So, hopefully, by the time people start using it, all relevant version of Python supports it.
kamyarg 6y ago
> PEP 604: New Type Union Operator¶ > Union[int, float] -> int | float Really excited for the new syntax, thank you everyone involved for making Python better each day. IMO Python's most powerful feature is its' amazing community. :) btw there is a small typo @ https://docs.python.org/3.10/whatsnew/3.10.html https://docs.python.org/3.10/whatsnew/3.10.html: > Pattterns -> Patterns Does anyone know where it needs to be fixed?
- ktpsns 6y ago
  There's a "Show Source" link in the navigation that points to https://github.com/python/cpython/blob/master/Doc/whatsnew/3.10.rst https://github.com/python/cpython/blob/master/Doc/whatsnew/3...
  - kamyarg 6y ago
    Thank you for the pointer. Seems they have already fixed it. https://github.com/python/cpython/pull/24721/files https://github.com/python/cpython/pull/24721/files
- vgwilliams 6y ago
  It is not a community. It is a tightly knit group of people who have the right positions and who follow the religion of the day. Most valuable contributions come from people who come and go and never had any real power. Currently you get real power by working for the right corporations regardless of your contributions. A decade ago it was more benign, the independent people were also respected. To avoid this parochialism and nepotism, Python needs a standard and multiple implementations. C++ is a much nicer community for people who do actual work.
KptMarchewa 6y ago
Pattern matching is the first major feature in Python for a long time I'm really excited about.
ksm1717 6y ago
Anyone have a clever solution for optionally using new python features while still supporting lower python 3 versions? For packaging purposes. Could put try except blocks everywhere or selectively import 3.10 modules vs <=3.9 modules, for example. I find that new features aren’t necessary for their functionality, but they often can make code more terse, so having “duplicate” code with the same functionality but without new terseness kind of defeats the purpose. I suppose having two versions of the same module lets you end support for an old version pretty simply, but is that useful?
- aflag 6y ago
  I think there are packages that detect the python version and do some crazy stuff in setup.py. But I think the most responsible thing for a widely used library to do is hold back on using new python features until they are a few years old.
belval 6y ago
Maybe I've been working with Python for too long but I don't see the value in Python's pattern matching. if/elif/else are all four letters just like case and I remember reading that Guido didn't want a match and case construct. Maybe I am just grumpy but I feel like Python the simple language that drew in a lot of developer is going the C++ way of adding features for the sake of adding features.
- wodenokoto 6y ago
  Have a look at the the tutorial pep and you'll realize like I did, that pattern matching and case switches solve very different use cases, and that if-else are a long shot from pattern matching. https://www.python.org/dev/peps/pep-0636/ https://www.python.org/dev/peps/pep-0636/ > and I remember reading that Guido didn't want a match and case construct. look at who the sponsor of that pep is.
  - belval 6y ago
    I can absolutely see that it could be useful, what I am saying is that I would prefer the language to stay lean and steer away from adding features offering minimal quality of life improvements. As for Guido being the sponsor, he also pushed for it in 2006 and it was rejected for lack of popular support. His opinion back then still resonates with me today: https://www.python.org/dev/peps/pep-3103/#rationale https://www.python.org/dev/peps/pep-3103/#rationale

125 points by pansa2 6y ago

Exciting! Especially I like the named attribute matching [1] and dict matching [2]. Scala does not have that. If you have a case (data) class with 13 parameters, you need to match on all of them, instead of doing `MyClass(param=value)`. Similarly you can not easily pattern match on `Map` (`dict`). One thing which I am missing though is matching on f-strings. Such a powerful feature in Scala. [1] https://www.python.org/dev/peps/pep-0636/#adding-a-ui-matching-objects https://www.python.org/dev/peps/pep-0636/#adding-a-ui-matchi... [2] https://www.python.org/dev/peps/pep-0636/#going-to-the-cloud-mappings https://www.python.org/dev/peps/pep-0636/#going-to-the-cloud...

0x008 6y ago
I don’t understand what you are saying? In scala you do not have to match on all parameters. You can use the underscore operator to skip the other attributes. Also you can match a map since every map is just a sequence of Tuples in scala. However why would you ever do this? It is really impractical for large sequences and if I have only a very limited number of attributes I would not use a map I guess.
- tomsmeding 6y ago
  > You can use the underscore operator to skip the other attributes And have to add an underscore in the right position when you ever add an attribute? With partial matching like described, you don't have to change the pattern when adding fields to the data structure. I guess the GP was referring to this.
  - 0x008 6y ago
    Well that is a little bit different I guess. You probably could do some unapply shenanigans to achieve the same result but that off the top of my head I would not know how to do that.
- vletal 6y ago
  Well sure, wildcards still count as matching. The ability to use named params instead could clean some codebases a bit. Also I get that there are reasons for the Map matching not being present in Scala. All I am saying is that it's cool that it's in python.
dividedbyzero 6y ago
You can use guards to achieve a lesser version of this in Scala, e.g.: case x:YourCaseClass if(x.oneField=="value") => ...

tus89 6y ago

This is nice and all, but part of me feels like having code structured around the shape of tuples returned by functions has an element of pattern-smell (and by pattern I mean design pattern).

_ZeD_ 6y ago
If this can make feel better, you can type-alias the tuple shape and "squint" them as classes
coldtea 6y ago
>having code structured around the shape of tuples returned by functions has an element of pattern-smell (and by pattern I mean design pattern). This is a near content-less critique, which amounts to: "shaping code around what's returned by functions looks like a design pattern (and implied: design patterns are bad)" Well, design patterns are neither bad, nor good. They are what they are: a high level description of common solutions to common problems. By themselves design patterns are not problems or problematic. It's applying them where they don't fit the problem - or where something simpler will suffice - that's problematic (common e.g. to J2EE era Java). Some also say that design problems point to a language deficiency (that is, make up for a lack of language feature, like e.g. closures or dynamic typing). If we accept the above folk wisdom, built-in pattern matching would be the exact opposite of what you say. It wouldn't be a "design pattern smell" but rather a first-class feature that frees you from having to workaround its lack with design patterns. But I'd go further and say that the complain is nonsensical anyway. What exactly does "having code structured around the shape of tuples returned by function" even mean? If there's a need to extract values from the results of a function (e.g. in a parser, a protocol handler, etc.) then we don't have alternatives, we will structure our code "around the shapes returned". The question if whether we will do it through ad-hoc solutions (like chained "if" statements, a series of switch/case, etc.), through some convoluted design pattern like a Visitor, or by first class support for exactly our need. This first class support is exactly what pattern matching syntax offers. And far from being some smell/Python novelty, it's an old staple found in Haskell, ML, Ocaml, Lisp, and several other places besides...
- 6y ago

guram11 6y ago

While I embrace this feature something about using "equal/assignment" bothers me, I prefer "as" binding in "with" statement style case Point as (0, y):

quietbritishjim 6y ago
That doesn't resolve (at least not obviously to me) the ambiguity where you want to match a Point where the first value is equal to the existing variable x, while the second value is anything and you want to capture it in a new variable y. I prefer the suggestion that appeared at one point where captured variables would have to be suffixed with ?, like this: case Point(x, y?): For those not aware, the solution today is that x must contain a . in its name by virtue of being a member of an object or an imported module: case Point(something.x, y):
- coldtea 6y ago
  >the solution today is that x must contain a . in its name A crappy solution, if I ever saw one...
- pkolaczk 6y ago
  case Point(x, y) if x == something Where's the problem?
  - quietbritishjim 6y ago
    Syntax cleanliness is ultimately subjective, so if you don't see a problem with that then I don't think I can persuade you. To me, it just seems obvious that it's more painful than what I wrote. But I'll mention a couple of specific reasons anyway: * The most concerning thing is knowing to write that in the first place. I think that if the ? syntax were the real one then you'd soon get used to writing a snippet like in my comment, but with the current syntax it's always going to take a bit of mental mind bending to come up with what you've written. * Even if you get it right when writing it, what you've written is vastly more verbose, and adding that redundant variable name (twice!) is just going to be distracting when reading it back. By the way, what you wrote is not equivalent to what I wrote (I wonder if that means your snippet is not as obvious as you're suggesting): you've matched against "something" rather than "x". Instead you'd need to do: case Point(also_x, y) if also_x == x:

Uzomidy 6y ago

It's not 100% more — 100% would be twice as much. In this case, we've gone from none at all to having some, which is infinitely more.

DemocracyFTW 6y ago
Came here to say that, am satisfied. It was twice as cold on Monday than it was on Sunday. /duck
- teekert 6y ago
  If you'd use Kelvin I'd be ok with your remark, although I'd be wondering on what planet you live.
  - kubanczyk 6y ago
    My guess it was just at Moon's terminator. (Parent didn't say "planet".) Can quickly go from 300 K to 150 K, source https://ars.els-cdn.com/content/image/1-s2.0-S0019103516304869-gr5.jpg https://ars.els-cdn.com/content/image/1-s2.0-S00191035163048...
ghego1 6y ago
Thanks for the clarification! I am relatively new to python and I thought that I had not noticed this feature :-D
tpoacher 6y ago
and don't get me started on "biweekly"
- OJFord 6y ago
  That really is a weird one, because here in the UK we say 'fortnightly' (for 'every other week'); so 'biweekly' would definitely be taken to mean 'twice per week'. That also matches 'biannual' (an event that occurs every other year is 'biennial'), so 'biweekly' as 'fortnightly' is certainly to be proscribed, in my book.

a-dub 6y ago

does this mean that python has graduated from lisp without parens to ml without 'let'? (less 'fun' ml?)

bjoli 6y ago
Why do would you say python is like a lisp without parens? Common lisp is warty, battle tested and productive - but the similarities end there. I tried to use Hy, but even with the most glaring difference mitigated, python felt nothing like lisp. I was still writing very much python.
- a-dub 6y ago
  map, reduce, filter, lambda, etc sure, no car, cdr or cons, but you can do that with list notation and it's cleaner anyhow.
  - smitty1e 6y ago
    > map, reduce, filter, lambda, etc Those are generally functional, not lisp-specific, concepts.
    - a-dub 6y ago
      ...aaand the first language to define them was...
      - pjmlp 6y ago
        Lambda calculus.
      - bjoli 6y ago
        probably APL, like all these things. It was probably used in some fashion before that, but my experience that is where it was named and standardised. Heck, it is even mapped to an ASCII character IIRC: \ or /. Can't remember which, and on GPRS so Google takes a good 2 minutes.

bluefox 6y ago

Can't wait to make my programs incompatible with all previous versions!

smitty1e 6y ago
"What do you mean it crashed? Just upgrade everything to the latest version."
nickjj 6y ago
Fortunately we have tools like Docker and to a lesser extent Python Virtual Environments to help deal with this in a sane way. But yeah for 1 off zero dependency Python scripts I won't be using the new features until major distros ship with 3.10 by default. Part of the appeal to me of Python is most distros and operating systems have it installed by default. Being able to curl down a single file and run it is really nice. For that to work requires using a version of Python that most folks have by default. That means coding against 3.6's features (at least we can use f-strings now!).
- Already__Taken 6y ago
  I haven't found this much use because you still can't assume the default version really and pip seems to be broken all the time by default.
singularity2001 6y ago
In utopia every new version would come with a tool to convert new code to old code (for all those non-nightly systems). ideally even with file extensions: .py3 runs on all python3 versions .py38 runs on all python3.9 versions and above
- aflag 6y ago
  That's not really enough as you depend on libraries you don't own. All the sudden in order to update a small library you use you need to update to a new version of Python. So, yeah, new syntax is always disruptive. My utopia has new syntax being added very seldomly with loads of notice period and a `from __future__ import newsyntax` phase before the syntax is considered "production ready". So, hopefully, by the time people start using it, all relevant version of Python supports it.

kamyarg 6y ago

> PEP 604: New Type Union Operator¶ > Union[int, float] -> int | float Really excited for the new syntax, thank you everyone involved for making Python better each day. IMO Python's most powerful feature is its' amazing community. :) btw there is a small typo @ https://docs.python.org/3.10/whatsnew/3.10.html https://docs.python.org/3.10/whatsnew/3.10.html: > Pattterns -> Patterns Does anyone know where it needs to be fixed?

ktpsns 6y ago
There's a "Show Source" link in the navigation that points to https://github.com/python/cpython/blob/master/Doc/whatsnew/3.10.rst https://github.com/python/cpython/blob/master/Doc/whatsnew/3...
- kamyarg 6y ago
  Thank you for the pointer. Seems they have already fixed it. https://github.com/python/cpython/pull/24721/files https://github.com/python/cpython/pull/24721/files
vgwilliams 6y ago
It is not a community. It is a tightly knit group of people who have the right positions and who follow the religion of the day. Most valuable contributions come from people who come and go and never had any real power. Currently you get real power by working for the right corporations regardless of your contributions. A decade ago it was more benign, the independent people were also respected. To avoid this parochialism and nepotism, Python needs a standard and multiple implementations. C++ is a much nicer community for people who do actual work.

KptMarchewa 6y ago

Pattern matching is the first major feature in Python for a long time I'm really excited about.

ksm1717 6y ago

Anyone have a clever solution for optionally using new python features while still supporting lower python 3 versions? For packaging purposes. Could put try except blocks everywhere or selectively import 3.10 modules vs <=3.9 modules, for example. I find that new features aren’t necessary for their functionality, but they often can make code more terse, so having “duplicate” code with the same functionality but without new terseness kind of defeats the purpose. I suppose having two versions of the same module lets you end support for an old version pretty simply, but is that useful?

aflag 6y ago
I think there are packages that detect the python version and do some crazy stuff in setup.py. But I think the most responsible thing for a widely used library to do is hold back on using new python features until they are a few years old.

belval 6y ago

Maybe I've been working with Python for too long but I don't see the value in Python's pattern matching. if/elif/else are all four letters just like case and I remember reading that Guido didn't want a match and case construct. Maybe I am just grumpy but I feel like Python the simple language that drew in a lot of developer is going the C++ way of adding features for the sake of adding features.

wodenokoto 6y ago
Have a look at the the tutorial pep and you'll realize like I did, that pattern matching and case switches solve very different use cases, and that if-else are a long shot from pattern matching. https://www.python.org/dev/peps/pep-0636/ https://www.python.org/dev/peps/pep-0636/ > and I remember reading that Guido didn't want a match and case construct. look at who the sponsor of that pep is.
- belval 6y ago
  I can absolutely see that it could be useful, what I am saying is that I would prefer the language to stay lean and steer away from adding features offering minimal quality of life improvements. As for Guido being the sponsor, he also pushed for it in 2006 and it was rejected for lack of popular support. His opinion back then still resonates with me today: https://www.python.org/dev/peps/pep-3103/#rationale https://www.python.org/dev/peps/pep-3103/#rationale