Python 3.10.0a6 is available, now with 100% more pattern matching
mail.python.org
mail.python.org
> 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:
> Pattterns -> Patterns
Does anyone know where it needs to be fixed?
Seems they have already fixed it.
It was twice as cold on Monday than it was on Sunday. /duck
Can quickly go from 300 K to 150 K, source https://ars.els-cdn.com/content/image/1-s2.0-S00191035163048...
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.
Except that's literally the dictionary definition of the word. And "biennial" and "biannual" are synonyms.
I only have Collins' concise to hand, which gives the definitions I have and doesn't even mention (not even proscribed or US etc.) other uses. And Collins is pretty permissive.
And no they're not. 'Biennial' events occur once per two year period; 'biannual' events occur four times per two year (twice per year) period.
For example, in horticulture 'a biennial [plant]' is one that has a single flowering/reproduction cycle over two years. (Cf. 'annuals', 'perennials'.)
(a, b, c, d) = range(4)
(a, b, c, d, e, f, g, h) = range(8)
It went from having 0 pattern matching to having 1 pattern matching -- that seems like '100% more of this thing we are talking about' to me. This of course only makes sense if you see '1 pattern matching' as a precisely defined abstract construct, but I guess the 100%-more joke usually requires that perspective (and is a joke precisely because it's so non-sensical to think this way).
This is what people normally learn in primary school about the meaning of this phrase.
case Point as (0, 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?):
case Point(something.x, y):A crappy solution, if I ever saw one...
case Point(x, y) if x == something
* 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:This is something you learn from reading the docs / book on the feature. This applies to all language features.
> Even if you get it right when writing it, what you've written is vastly more verbose
Slightly more verbose, but also more consistent with the rest of Python syntax. Python syntax already has `if` clause that's well understood, while you're proposing a special-case syntax. I believe language consistency beats brevity, and explicit is better than implicit.
BTW the ? syntax looks to me very similar to optional / null-aware / error-aware dereferencing operator used in some other languages (Kotlin, Groovy, Rust).
Surely you agree that, even having read and understood documentation for a language feature, there are differing levels of difficulty in using it? That depends on intrinsic complexity of the feature and also the incidental complexity from the design of the language feature. Your comment seems to imply that it doesn't matter what syntax the language feature uses because you'll have to learn about it in any case. I'm sure you don't really mean that!
> I believe language consistency beats brevity, and explicit is better than implicit.
I agree with both parts of this statement, I just disagree that the syntax they chose satisfies it.
The syntax is not consistent with anything else, because nowhere else can you have (0, x, foo.y) mean "assign to x (but don't assign to 0 or foo.y)". That includes if statements, with statements, and left hand side of assignment statements. Choosing a new syntax for something that has different behaviour from existing syntax actually is being consistent.
Similarly, using a character like ? (or some other distinctive syntax) to demark which parts are being used for pattern matching is being explicit. In Point(x, foo.y, 0), saying that only x is assigned to because it's not a literal or dotted seems like a great example of implicit behaviour to me.
Again, like I said at the start, this is all subjective so I think we'll have to agree to disagree. I just wanted to object to those quoted sentences because it looked like you were saying that it is objectively true that ? syntax is implicit and inconsistent while the syntax they chose is explicit and consistent - and that isn't objectively true.
I view pattern matching from a bit different angle - instead of viewing the case expression as answering "does the object match the pattern", I view it instead "can the object be deconstructed to a thing looking like the pattern". That is, if you write the exactly same expression after matching on the right side, it should evaluate to the original object being matched. And I believe this holds in Python just as in other languages with pattern matching.
However, Python way of making it work is indeed a bit strange - because pattern matching is allowed to mutate variables from the outer scopes, while in some other languages I'm used to, capturing symbols just shadow the symbols in the outer scope, without changing them. This is a bit scary part of Python implementation.
case Point(== x, y):``` (with [f open(file 'r)] (do stuff))
```
rather than
``` with open(file,'r') as f:
```
I switch [1] to Python (often to write tests in a language the node.js crew will be able to skim) and the one thing that trips me always is the wrong ordering of the `with` statement in straight Python. You don't say `for range(10) as x`...
I hope the Hy crew do the sensible thing about case statements. I don't even know what the sensible thing is, though.
[0] http://hylang.org [1] Yes, you can import Hy code from Python and vice-versa!
Are you using it in any public projects?
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!).
ideally even with file extensions: .py3 runs on all python3 versions .py38 runs on all python3.9 versions and above
It's a total 180 from when he pushed python 2 when it only had a few years until it's EOL.
Like f-strings look nice and all but there's nothing wrong with the format method and there's always the locals hack to achieve the same thing.
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.
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.
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
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...
I am honestly amazed you could interpret it that way, rather than the intended: it seems like a questionable design pattern.
> What exactly does "having code structured around the shape of tuples returned by function" even mean?
To me it sort of implies a function is serving multiple purposes, essentially multiple functions mashed into one -- and you figure out what really happened by the shape of it's return value. It seems to go against everything we think of functions as pure-as-possible constructs that do one thing well, and that is represented by a clearly defined return value.
I agree there might be edgy uses cases like parsers -- but few people are really writing compilers/protocol handlers, and I am afraid that first-class features might be misused by less experienced programmers who start to write frankenfunctions coupled with convoluted pattern-match blocks -- as opposed to traditional, elegant functional decomposition.
And I think functional languages are fine, however I don't always agree that just because a feature works well in the FP space it is a good idea to bring it in as a first class feature into a OO/imperative language...
"Design patterns are bad" is an often repeated "folk wisdom" in dev circles. So by under-definining what's meant (leaving it open to interpretation) it's a very easy intepretation for others to assume of the comment.
The wording supports this too:
"has an element of pattern-smell (and by pattern I mean design pattern)"
This doesn't seem to imply "questionable design pattern", but "this smells like a pattern", and given that you object to it, one assumes that for you "smelling like a pattern" is bad.
Also, "seems like a questionable design pattern" would be a bizarre interpretation to take -- as this is a first-class syntax, not a design pattern.
>To me it sort of implies a function is serving multiple purposes, essentially multiple functions mashed into one -- and you figure out what really happened by the shape of it's return value. It seems to go against everything we think of functions as pure-as-possible constructs that do one thing well, and that is represented by a clearly defined return value.
I see where you're coming from, but there's nothing really violating purity here, or even "clearly defined return values".
Those clearly defined return values could still take several variations of a shape or even several shapes. Those won't have to be arbitrary shaped or non-pure. It's about handling a class of shapes.
AST nodes for example from a parsing function, protocol parts from a protocol handler, network responses in a server that might or might not have a payload, game states in a logic loop, and so on, fall into this. And pattern matching allows you to handle this common need easily.
So it's not like (pseudocode):
match(foo):
foo ~= duck: ..
foo ~= 5: ..
foo ~= "a string": ..
foo ~= triangle: ..
match(astNode):
foo ~= expression: ..
foo ~= statement: ..
foo ~= variable: ..
Not the OP, but pattern matching makes the code more concrete and less abstract. Looking at it from another point of view, it is the opposite of duck typing. Or makes things less generic. Now you need to pass in a tuple, where as for a different solution, a tuple could have been used, or a list, or your own class that responds to __getitem__, etc.. This is a well known limitation in the Haskell world.
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-matchi...
[2] https://www.python.org/dev/peps/pep-0636/#going-to-the-cloud...
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.
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.
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.
case x:YourCaseClass if(x.oneField=="value") => ...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?
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.
sure, no car, cdr or cons, but you can do that with list notation and it's cleaner anyhow.
That could be Java or C++.
From almost every language I have used, I find python one of the furthest from my idea of functional programming (which means different things to different people). Which, in my mind, also makes it a pretty darn useless ML. It is a fine language on its own, but understanding it in terms of lisp (or even worse, scheme) or, say, standard ML is a not very useful.
I think a good exercise regarding this is trying to write YOUR-FAVOURITE-LANGUAGE in ANOTHER-LANGUAGE.
Writing idiomatic scheme in standard ML is surprisingly straightforward. Writing scheme in python is awful, regardless of functools.
It's like a weird version of linear types where every value is only allowed to be used once.
Those are generally functional, not lisp-specific, concepts.
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.
Reduce and Compress are both denoted / which is sometimes a problem.