Hi Oscar,
Thanks for the feedback.
On 27/03/2021 4:19 pm, Oscar Benjamin wrote:
On Sat, 27 Mar 2021 at 13:40, Mark Shannon <m...@hotpy.org> wrote:
Hi Mark,
Thanks for putting this together.
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.
It would take me some time to compare exactly how this differs from
the current state after PEP 634 but I certainly prefer the
object-model based approach. It does seem that there are a lot of
permutations of how matching works but I guess that's just trying to
tie up all the different cases introduced in PEP 634.
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.
Maybe I misunderstood but it looks to me as if this (PEP 653) changes
the behaviour of a mapping pattern in relation to extra keys. In PEP
634 extra keys in the target are ignored e.g.:
obj = {'a': 1, 'b': 2}
match(obj):
case {'a': 1}:
# matches obj because key 'b' is ignored
In PEP 634 the use of **rest is optional if it is desired to catch the
other keys but does not affect matching. Here in PEP 653 there is the
pseudocode:
# A pattern not including a double-star pattern:
if $kind & MATCH_MAPPING == 0:
FAIL
if $value.keys() != $KEYWORD_PATTERNS.keys():
FAIL
I missed that when updating the PEP, thanks for pointing it out.
It should be the same as for double-star pattern:
if not $value.keys() >= $KEYWORD_PATTERNS.keys():
FAIL
I'll update the PEP.
My reading of that is that all keys would need to be match unless
**rest is used to absorb the others.
Is that an intended difference?
Personally I prefer extra keys not to be ignored by default so to me
that seems an improvement. If intentional then it should be listed as
another semantic difference though.
I don't have a strong enough opinion either way.
I can see advantages to both ways of doing it.
E.g. With PEP 653, pattern matching will work in the collections.abc
module. With PEP 634 it does not.
As I understood it this proposes that match obj: should use the class
attribute type(obj).__match_kind__ to indicate whether the object
being matched should be considered a sequence or a mapping or
something else rather than using isinstance(obj, Sequence) and
isinstance(obj, Mapping). Is there a corner case here where an object
can be both a Sequence and a Mapping? (How does PEP 634 handle that?)
If you define a class as a subclass of both collections.abc.Sequence and
collections.abc.Mapping, then PEP 634 will treat it as both sequence and
mapping, meaning it has to try every pattern. That prevents the
important (IMO) optimization of checking the kind only once.
Cheers,
Mark.
Not using the Sequence and Mapping ABCs is good IMO. I'm not aware of
other core language features requiring the use of ABCs. In SymPy we
have specifically avoided them because they slow down isinstance
checking (this is measurable in the time taken to run the whole test
suite). Using the ABCs in PEP 634 seems surprising given that the
original pattern matching PEP actually listed the performance impact
of isinstance checks as part of the opening motivation. Maybe the ABCs
can be made faster but either way using them like this seems not in
keeping with the rest of the language.
Oscar
_______________________________________________
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/WCN3P4XYVWGL4UTEHNYO2LJO5ULZY3GI/
Code of Conduct: http://python.org/psf/codeofconduct/
