[Python-ideas] Match statement brainstorm

[Michael Selik]

On Tue, May 24, 2016 at 7:03 PM Greg Ewing <greg.ewing at canterbury.ac.nz>
wrote:

> Michael Selik wrote:
> > My main point is
> > that switch/case/matching is semantically identical to if/elif, so why
> > use something different?
>
> But then you say
>
>  > No, using the assign-if-can operator would be syntax error outside of an
>  > if/elif, the reverse of how an assign operator is a syntax error inside
>  > an if/elif.
>
> So what you're proposing is *not* semantically equivalent
> to composing the existing if/elif with a new pattern matching
> assignment, which means re-using the existing keywords for
> it is misleading.
>

Perhaps I didn't explain my proposal correctly. I spent about 3 hours this
evening writing out a more thorough proof of the semantic equivalence. As I
did so, toying with different syntaxes, I realized that it might be better
to break this problem apart and solve a few subproblems first.

The first problem to solve is how to write a destructuring bind for more
than just sequences. Once we're happy with that, it'll be easier to discuss
pattern matching.

# Iterable-destructuring bind (a.k.a unpacking)
(a, b, *rest) = sequence

# Subscriptable-destructuring bind
{'x': p, 'y': q} = mapping
{0: p, 42: q, **rest} = indexable

# Attribute-destructuring bind (a few awkward ideas)
(.x: p, .y: q) = obj
(x=p, y=q) = obj

Or would you call that "object-destructuring"? No clue what the best name
is here. I think Clojure side-steps attributes and only provides
destructuring sequences and mappings. If you want to do pattern matching on
a more complex type, you must provide essentially a conversion from that
type to a mapping.

> The exception-catching expression is not meant to be available in
> > any other context. However, exception-catching is an essential feature
> > to matching via destructuring. I believe it's unavoidable, though
> > *which* exceptions are suppressed could be made more clear.
>
> my assumption was that there was nothing special about
> the right hand side, so the implementation would have to
> just evaluate all of it and catch any AttribteErrors,
> KeyErrors, IndexErrors, etc. emanating from it, which is
> much looser and prone to catching too much.
>
> But if the right hand side is special, all bets are off
> and you'll have to explain exactly what would be allowed
> and how to interpret it.
>

I agree that catching all exceptions during the assign-if-can (via if/elif
or switch/case) might be too error-prone. Whether it's the LHS of ``as`` or
the RHS of ``?=``, it would help to restrict the kind of exceptions
handled/suppressed as a failed match. However, I fail to see why ``case ...
as ...`` would be restrictive and ``if ... ?= ...`` would not. They could
have the same semantics, catching either a specific set of exceptions or
all/most exceptions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160525/f13b71f2/attachment.html>