Some comments:
* What you call "Constant Value Patterns" can really refer to any local
or non-local name, regardless of how complex the referred object is,
right? Also, __eq__ is called in that case, not __match__?
* If I understand correctly, these:
case b"":
print("it's an empty bytes object")
and
case bytes():
print("it's a bytes object")
have entirely different meanings. Am I right? This sounds like I have
to switch contexts when reading code, based on whether I am reading
regular code or a match clause, given that semantics are quite
different.
Instead, it seems like the latter would be more explicitly spelled out
as, e.g.:
case instanceof(bytes):
print("it's a bytes object")
* The acronym "ADT" is never defined.
* """If there are more positional items than the length of
__match_args__, an ImpossibleMatchError is raised."""
What if there are less positional items than ``len(__match_args__)``?
Can the match succeed rather than raise ImpossibleMatchError? This
seems potentially error-prone.
Overall, my main concern with this PEP is that the matching semantics
and pragmatics are different from everything else in the language.
When reading and understanding a match clause, there's a cognitive
overhead because suddently `Point(x, 0)` means something entirely
different (it doesn't call Point.__new__, it doesn't lookup `x` in the
locals or globals...). 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 <[email protected]> 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 -- [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/MVQJA7LDO4NNQEU27Q6ERUWC5GRBQ7SG/
Code of Conduct: http://python.org/psf/codeofconduct/
