On Thu, Nov 19, 2020 at 8:08 PM Brett Cannon <br...@python.org> wrote:
> > > On Thu, Nov 19, 2020 at 5:16 AM Steve Holden <st...@holdenweb.com> wrote: > >> On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset <dfmois...@gmail.com> >> wrote: >> >>> [sorry for the duplicate, meant to reply-all] >>> >>> Thank you for this approach, I find it really helpful to put the >>> conversation in these terms (semantics and guiding principles). >>> >>> It does help to rationalise discussion ;-) >> >>> [...] >>> 4. "Objects should be able determine which patterns they match." >>> This is something that you and I, and most of the authors of 622 agree >>> on. What we found out when discussing this is that we didn't have clear >>> what and how to open that customization. Some customization options added a >>> lot of complexity at the cost of performance, some others were very simple >>> but it wasn't clear that they would be actually useful, or extensible in >>> the future. This has a lot to do with this being a somewhat new paradigm in >>> Python, and our lack of knowledge on what the user community may do with it >>> beyond what we imagined. So the decision was "pattern matching as it is >>> presented without extensibility is useful, let's get this in, and once we >>> see how it is used in the wild we'll understand better what kind of >>> extensibility is valuable". For a crude analogy, imagine trying to get the >>> descriptor protocol right when the basic python object model was being >>> implemented. These things happened as different times as the use of the >>> language evolved, and my opinion is that customization of the match >>> protocol must follow a similar path. >>> >>> >> I haven't so far understood whether the change proposed is intended to >> start out in __future__. Given the preliminary nature of this development, >> it would seem wise to retain the option to withdraw it or modify it >> radically before production code depends on it. >> > > The current proposal is not for it to be put behind a __future__ statement > as it doesn't conflict with or break any pre-existing source code. > Ok, thanks for the clarification. All I will say is just because we aren't *required* to implement it in __future__ that doesn't mean we can't or shouldn't. Everything should be done to underline the tentative nature of these developments, or we risk the potential of functionality frozen because "we're already using it in production." The discussion to date suggests that such a breathing space would be useful.
_______________________________________________ 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/TUO5S5UZJ3SLNCM2DNCEJ5KTGYNDCAFD/ Code of Conduct: http://python.org/psf/codeofconduct/
