Hi Mark,
Quoting Mark Shannon <mark@hotpy.org>:
Hi Tobias,
[...]
But they are not referenced in PEP 634. I shouldn't have to trawl the internet to find the rejected ideas section.That paper describes a `__match__` method, which is absent from PEP 634.
Why?
Cheers,
Mark.
You are right: you should not have to trawl the internet to get these information. However, given the history of the Pattern Matching PEPs and that PEP 622 is linked directly from PEP 634, I would think it is not that far a journey—even though there have been so many discussions that it has definitely become unwieldy to retain an overview...
Anyway, the answer to both your questions lies in that the Pattern Matching feature itself is rather complex and the PEPs ended up being huge and hard to read and understand as it is. We therefore refrained from long lists of rejected ideas in PEP 634, since that has already been done in PEP 622. Moreover, the `__match__` method and protocol were removed from the PEPs to focus on a core infrastructure and keep it as simple as possible.
I think such a customisable protocol will eventually add great value to pattern matching. However, one of the main arguments was to wait until we have more experience with pattern matching in Python and can give specific use cases for this extended protocol, which allow us to guide the design of the protocol.
At the end of the day, I guess we quite agree that we would like to have `__match__`, `__deconstruct__` or whatever you want to name it. But the slight variations in design demonstrate that it might also be a good idea to carefully lay it out first, before adding it to the pattern matching engine. Hence, separating this from the core implementation seems like a good idea that I still fully support (despite also looking forward to having it some day in the future ^_^).
Cheers,
Tobias