I was talking with a colleague today about the PEP and he raised a couple
of question regarding the match protocol and the proxy result.

One question is that taking into account that 'case object(x)' is valid for
every object, but it does (could do) something different for objects
that have a non-None __match_args__ it seems that implementing
__match_args__ will break Liskov substitutability as you could not
substitute
the child in a context where you expect a parent.

Even if you don't care about Liskov substitutability seems that introducing
a __match_args__ for a class will almost always be backwards
incompatible. For example, let's say that 'datetime.date' doesn't have a
custom matching defined, so it inherits the default object.__match__,
 which does:

class object:
    @classmethod
    def __match__(cls, instance):
        if isinstance(instance, cls):
            return instance

The PEP notes that:
> The above implementation means that by default only match-by-name and a
single positional match by value against the proxy will work

Which means that users can do a positional match against the proxy with a
name pattern:

match input:
    case datetime.date(dt):
        print(f"The date {dt.isoformat()}"

Imagine that later, someone notices that it would be reasonable to support
structural pattern matching for the fields of a 'datetime.date' so that
users could do:

match birthday:
    case datetime.date(year) if year == 1970:
        print("You were born in 1970")

But, if 'datetime.date' were updated to implement a non-default
__match_args__, allowing individual fields to be pulled out of it like
this, then the first block would be valid,
correct code before the change, but would raise an ImpossibleMatch after
the change because 'dt' is not a field in __match_args__.

Is this argument misinterpreting something about the PEP or is missing some
important detail?

On Wed, 24 Jun 2020 at 20:47, Guido van Rossum <gu...@python.org> wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
> _______________________________________________
> 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/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/
> 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/T32GEZA43AE6LDSAG35I3F2ITXJ5SPTJ/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to