Hi Mark,
Thank you for your proposal to try and have more precise semantics for
pattern matching. Of course, the proposal primarily introduces a new
and extended protocol for pattern matching, upon which the 'semantics'
is then based. I think it is important to recognise and discuss your
work on this basis that it proposes a different protocol of how
pattern matching works, before we consier whether your semantics
really is 'more precise'.
As I understand it, your PEP proposes two major differences: control
over the matching process moves from patterns to the objects and a
custom protocol is introduced (via the `__deconstruct__` method).
There is also the matter of the `__match_kind__` with the intention of
improving performance, which I find of minor importance here.
If you go back and look at the history and development of PEP 634, you
will find that we started off with a fully customisable method that we
called `__match__` instead of `__deconstruct__`. The idea of more
flexible and customisable pattern matching is thus certainly in the
spirit of our proposal as well. However, we finally removed this part
from our proposal due to strong concerns from the community that the
match protocol is too complex, particularly for an initial version of
pattern matching. Should the need arise, it would still be possible
to later add such a customisation protocol in an upcoming version of
Python.
Given these concerns with respect to complexity and our concession to
remove the `__match__` method, I am wondering: do you have strong
arguments that would speak for inclusion of this feature in the first
version of pattern matching after all? I would love to have this
feature and am truly interested in any arguments in its favour.
When pattern matching meets OOP, there is indeed some discussion that
can be had on where the matching itself is to happen. Simply put:
should an object recognise that it is an instance of a given class, or
should the class recognise that an object is an instance of it?
In the spirit of Python's `instancecheck` method, we opted for
classes/patterns recognising whether an object matches, where the
object itself is 'passive'. In other words, `case C()` would match
any object that is an instance of a subclass of `C`, in line with
usual OOP principles (where any instance of a subclass of `C` is still
a valid instance of `C` itself).
Your design turns this around and has the object take on the
responsibility of checking whether it wants to match a specific
pattern. This has the advantage that the object itself can morph into
anything it wants to—as long as it is aware of the pattern. And
therein lies the problem that IMHO fully negates one of the major
advantages of pattern matching: that the patterns and the objects that
are to be matched are de-coupled and fully independent. In other
words: in your design it is not she who writes the patterns that
controls what objects match, but he who designs the class hierarchy of
the objects used.
One of the great traits of pattern matching is that it works
out-of-the-box even with objects from ancient or alien code bases.
Pattern matching according to PEP 634 is isolated, it happens only
where pattern matching is explicitly used. When writing classes, you
do not have to worry about pattern matching at all, unless you want
your classes to be used as patterns. And should we decide some time
in the future that we want to introduce new kinds of patterns, we
still do not have to change a single object because the matching
happens in the patterns and not in the objects, anyway. That his
would not be the case with your design is already obvious with the
list of `__match_kind__` for common builtin classes, for instance.
Although there are some other programming languages that chose to
follow this route, I think it goes against the spirit of what is
already there in Python, it violates the principle of separated
concerns and is thus a rather ill-advised modification of the original
protocol.
Kind regards,
Tobias
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/7UIKPFTOU6APJGHW35A3P4JV4N6PL7K7/
Code of Conduct: http://python.org/psf/codeofconduct/
