Hello,
On Sun, 10 Jan 2021 12:08:05 +1000
Nick Coghlan <ncogh...@gmail.com> wrote:
[]
> PEP 634 doesn't have that feature for class patterns in general, only
> for classes like data classes, where the constructor signature is
> carefully aligned with the match arguments.
You see, if PEP622/PEP634 contained clause like: "class patterns may be
applied only to namedtuple types (and their subclasses) and dataclasses
(and their subclasses)", then I personally would be happy. But if
PEP622 draft would have contained such a clause, it would be removed
before publishing anyway, because:
1. Enforcing such a check is more trouble/overhead.
2. There's no need to police users such deep, e.g. what if someone
writes a class which has API *like* namedtuple/dataclasses, without
formally being one?
And that's the point. If you have a class:
class MyCls:
def __init__(self, val, nm):
self.val = val; self.name = nm
, and you normally use it like: MyCls(nm="foo", val=123), then when
you'll try to use it with pattern matching, you'll immediately see
what's wrong with your class: you need to use the same name for
constructor arg and a related attribute (if you don't want to see funky
discrepancies).
To come to that, you don't need to read anything, it'll come naturally.
In full accordance with Python approach of "gentle, but exciting (not
depressing) and eventually high, learning curve", where next step is
naturally guided by your previous steps.
And of course, for people who prefer to read, PEP634/etc. in
"informational" part should have a recommendation like "Class pattern
matching syntax best works with namedtuples and dataclasses, or classes
which follow their design pattern of "no data hiding", e.g. names of
attributes should match names of constructor arguments, as both are
public interface of such a class".
> For positional args, PEP 642 would also align in those carefully
> constructed cases, so it's only the new syntax for attribute matching
> where things differ.
And that's the biggest trouble with PEP642. "Conflating set syntax with
dict semantics" is an easy case (to both see and fix), that's why I
talked about it first.
Introducing 2nd syntax to match against objects, so, there're two
syntaxes to use against objects, and one of them is completely new
to Python - that's the real problem of PEP642.
And I patiently continue this thread, hoping that people whose argument
would be along the lines of "I teach Python, and I don't want to teach
my students 2 ways of doing the same thing, and which way use when. Why,
if PEP634 offers just one way?"
--
Best regards,
Paul mailto:pmis...@gmail.com
_______________________________________________
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/CVSPPY6B7NTY6CP7K77YLYHHRUB7PKLS/
Code of Conduct: http://python.org/psf/codeofconduct/
