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
guido@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-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/
>
