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.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/R2LI27QIV4GDM4PTBI5U63DDPPOMAB6T/
Code of Conduct: http://python.org/psf/codeofconduct/
