On 24/06/20 5:20 am, Antoine Pitrou wrote:
suddently `Point(x, 0)` means something entirely different (it doesn't call Point.__new__, it doesn't lookup `x` in the locals or globals...).
This is one reason I would rather see something explicitly marking names to be bound, rather than making the binding case the default. E.g. case Point(?x, 0): This would also eliminate the need for the awkward leading-dot workaround for names to be looked up rather than bound. The PEP says this was rejected on the grounds that binding is more common than matching constants, but code is read more often than it is written, and readability counts. It would also help with the problem that in case Spam(foo = blarg): the name being bound is on the right, whereas in case Spam(foo := Blarg()): the name being bound is on the left. I found myself having to think quite hard while reading the PEP to keep these two straight. With explicit marking of bound names, they would be case Spam(foo = ?blarg): case Spam(?foo := Blarg()): which, particularly in the first case, would make it much clearer what's being bound. One other thing that the PEP doesn't make clear -- is it possible to combine '=' and ':=' to match a keyword argument with a sub pattern and capture the result? I.e. can you write case Spam(foo = foo_value := Blarg()): ? -- Greg Obviously, there are cases where this is
worthwhile, but still.
It may be useful to think about different notations for these new things, rather than re-use the object construction notation.
For example:
case Point with (x, y): print(f"Got a point with x={x}, y={y}")
or:
case Point @ (x, y): print(f"Got a point with x={x}, y={y}")
(yes, "@" is the matrix multiplication operator... but it's probably much less likely to appear in common code and especially with a class object at the left)
Regards
Antoine.
On Tue, 23 Jun 2020 09:01:11 -0700 Guido van Rossum
wrote: I'm happy to present a new PEP for the python-dev community to review. This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin.
Many people have thought about extending Python with a form of pattern matching similar to that found in Scala, Rust, F#, Haskell and other languages with a functional flavor. The topic has come up regularly on python-ideas (most recently yesterday :-).
I'll mostly let the PEP speak for itself: - Published: https://www.python.org/dev/peps/pep-0622/ (*) - Source: https://github.com/python/peps/blob/master/pep-0622.rst
(*) The published version will hopefully be available soon.
I want to clarify that the design space for such a match statement is enormous. For many key decisions the authors have clashed, in some cases we have gone back and forth several times, and a few uncomfortable compromises were struck. It is quite possible that some major design decisions will have to be revisited before this PEP can be accepted. Nevertheless, we're happy with the current proposal, and we have provided ample discussion in the PEP under the headings of Rejected Ideas and Deferred Ideas. Please read those before proposing changes!
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/MVQJA7LD... Code of Conduct: http://python.org/psf/codeofconduct/