Hi Oscar

Quoting Oscar Benjamin <oscar.j.benjamin@gmail.com>:

On Fri, 19 Feb 2021 at 15:41, Tobias Kohn <kohnt@tobiaskohn.ch> wrote: [...]

It's not easy now to look back over the history of all of this. My
recollection of the original version of PEP 622 (if that's the right
one...) was that it had an overcomplicated protocol for __match__. It
needed to be simplified but in the end it was dropped.

Without further context, I would agree with you: it is difficult to look back over the entire history of the pattern matching PEPs.  However, on the one hand PEP 622 is directly linked in the current PEP 634.  On the other hand, for those who actively particiated in the discussion of both PEP 622 as well as the DLS paper, I find it a bit too easy and 'convenient' to call those resources now 'hard to find'.

That being said, I think it is part of your homework to first research about the history and what others have done before proposing your innovation.  Granted, this is hard and very laborious work that often takes a long time and can be frustrating.  But if we want to make progress and move forward, we have to stop running in circles.—To be absolutely clear here: I do not think that Mark's proposal is running in circles and I think it is fair enough to bring up these ideas.  But I equally think it is well possible to acknowledge that one part of it is a discussion of existing ideas, and to have a look at why these ideas have not made it into PEP 634.
 

The question now is if it will be straight-forward to retrofit a
protocol to PEP 634 after it is released and when backward
compatibility constraints kick in. PEP 653 (as discussed here) is
precisely an attempt to retrofit a protocol to PEP 634. I think the
difficulties involved in achieving that will become harder rather than
easier in future.

--
Oscar

There are actually two protocols in PEP 653.  One is about changing the fundamental design of pattern matching as outlined in PEP 634.  This is a part that I reject for reasons presented in one of my last posts.  The second one is the customisation part using `__deconstruct__` or `__match__`.  This is something that I like a lot and would certainly like to see in pattern matching—alas, just being in favour of something is not a strong enough argument for it.

Similar to my votum above: if we are going to discuss this, I think we need new arguments or evidence, something to show why the previous decision to drop it (for now) was wrong.  For that it might be worth reading the respective section in deferred ideas of PEP 622.  Some part of our decision was based on the notion that adding such a custom protocol later one will be relatively painless, but if we were wrong, please speak up and show us what we have overlooked.  If you can present, for instance, some real-world use cases where this feature would enormously benefit sympy (or any other popular package), that would be helpful and a good starting point.

Kind regards,
Tobias