Christopher Barker writes:
I don’t- I have the idea that Python itself is not really about Types.
Of course it is, and always has been. Types are even first-class objects in Python. What Python has never been about is universal type-checking.
Honestly, it makes me nervous when supposedly “optional” type hints start making their way into built in parts of the language and standard idioms.
Type hints are easily recognizable from the syntax, and match statements aren't that. This isn't creeping typing-ism at all. Python has *always* (at least since 1996 or so when I first encountered it) made "look before you leap" and "dispatch on type" styles possible. The match statement is clearly about enabling exactly the latter kind of programming:
Matt del Valle writes:
Matching on type is one of the main examples the tutorial PEP showed off (see the example where an event is matched against several different types such as Click, KeyPress, or Quit).
I guess my feeling is that there are better ways to solve those kinds of problems in Python.
Like what? Dispatching on type is fundamental to event-oriented programming. Of course you can write if isinstance(event, Click): x = event.position.x y = event.position.y button = event.b handle_click(x, y, button) or if isinstance(event, Click): handle_click(event.position.x, event.position.y, event.button) instead of match(event): Click(position=(x, y), button): handle_click(x, y, button) and I can see an argument that the former is "just as good" as the latter and we don't need match, but now that we do have the match statement, I can't see any argument that either if form is *better*.
This is the key point — and you are quite right. I’ll let others comment on whether this extension to pattern matching makes sense — I haven’t really dig into it enough to have an opinion.
About Matt's variadic container matching: My guess is that it was considered, but it's not easy to find pleasant applications because you can only do (x, y, *rest) = whatever destructuring on the whole sequence, which is a one-liner in a case that catches sequences. The typecheck for simple types such as str or even a user-defined class is also a one-liner (all(isinstance(o, type) for o in container). I don't think turning those three lines into one is irresistably attractive, which means it's most interesting for a case where you have a "type" defined inline (typically as a dict, I guess). I'm not sure how common that is. And in a case like: match mailbox: case [*{"From" : author, "To" : recipient, "_payload" : body}]: do_something(mailbox) isn't do_something very likely to be of the form for message in mailbox: do_something(message) and you have to destructure message explicitly anyway? So in such cases I would expect that for message in mailbox: match message: case {"From" : author, "To" : recipient, "_payload" : body}: do_something(author, recipient, body) is a simple and obvious transform. On the other hand, typecheck failures on objects in a container can be expensive if the container is large. You can only recover from them by checking for a container of untyped objects, and then handling that elementwise anyway. So on general principles, I don't think this idea is bad on the face of it, but it's not obviously great, either. The usual policy in such cases is to wait for a killer app before adding the feature (cf. the @ operator, which waited for literally decades despite having an obvious killer app, at least for a couple of communities that were pretty large then and are huge now). If you really could use match(data) to parse data and create a DataFrame in pure Python, that would be a strong PoC, though not yet a killer app since I doubt Pandas would use it. Obviously something sufficiently performant to be widely used would be nice.