Hi Mark,
I also wanted to give some feedback on this. While most of the
discussion so far has been about the matching of the pattern itself I
think it should also be considered what happens in the block below.
Consider this code:
```
m = ...
match m:
case [a, b, c] as l:
# what can we safely do with l?
```
or in terms of the type system: What is the most specific type that we
can know l to be?
With PEP 634 you can be sure that l is a sequence and that it's length
is 3. With PEP 653 this is currently not explicitly defined. Judging
from the pseudo code we can only assume that l is an iterable (because
we use it in an unpacking assignment) and that it's length is 3, which
greatly reduces the operations that can be safely done on l.
For mapping matches with PEP 634 we can assume that l is a mapping. With
PEP 653 all we can assume is that it has a .get method that takes two
parameters, which is even more restrictive, as we can't even be sure if
we can use len(), .keys, ... or iterate over it.
This also makes it a lot harder for static type checkers to check match
statements, because instead of checking against an existing type they
now have to hard-code all the guarantees made my the match statement or
not narrow the type at all.
Additionally consider this typed example:
```
m: Mapping[str, int] = ...
match m:
case {'version': v}:
pass
```
With PEP 634 we can statically check that v is an int. With PEP 653
there is no such guarantee.
Therefore I would strongly be in favor of having sequence and mapping
patterns only match certain types instead of relying on dunder
attributes. If implementing all of sequence is really to much work just
to be matched by a sequence pattern, as PEP 653 claims, then maybe a
more general type could be chosen instead.
I don't have any objections against the other parts of the PEP.
Adrian Freund
On 3/27/21 2:37 PM, Mark Shannon wrote:
> Hi everyone,
>
> As the 3.10 beta is not so far away, I've cut down PEP 653 down to the
> minimum needed for 3.10. The extensions will have to wait for 3.11.
>
> The essence of the PEP is now that:
>
> 1. The semantics of pattern matching, although basically unchanged,
> are more precisely defined.
>
> 2. The __match_kind__ special attribute will be used to determine
> which patterns to match, rather than relying on the collections.abc
> module.
>
> Everything else has been removed or deferred.
>
> The PEP now has only the slightest changes to semantics, which should be
> undetectable in normal use. For those corner cases where there is a
> difference, it is to make pattern matching more robust.
> E.g. With PEP 653, pattern matching will work in the collections.abc
> module. With PEP 634 it does not.
>
>
> As always, all thoughts and comments are welcome.
>
> Cheers,
> Mark.
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/YYIT3QXMLPNLXQAQ5BCXE4LLJ57EE7JV/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/OAVTGQCFXNX47JH52ZMOAHVISDZ2JNMO/
Code of Conduct: http://python.org/psf/codeofconduct/
