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 <gu...@python.org> 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-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/MVQJA7LDO4NNQEU27Q6ERUWC5GRBQ7SG/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
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/DVBQPTCNPTXTQULGZRH4LZEBNC2FWQAV/
Code of Conduct: http://python.org/psf/codeofconduct/
