Hi Oscar
Quoting Oscar Benjamin <[email protected]>:
On 2021年2月19日 at 15:41, Tobias Kohn <[email protected]> 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
_______________________________________________
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/7EK4K36F6NKD67VTBS2XWRXAN4E737AD/
Code of Conduct: http://python.org/psf/codeofconduct/