On Sun, Jun 28, 2020 at 8:44 AM Jim J. Jewett <jimjjew...@gmail.com> wrote:
> I actually like that it looks like instantiation; it seems to be saying
> "Do we have the sort of object we would get from this instantiation?"
>
> Unfortunately, this does aggravate the confusion over whether a variable
> is being used as a filter, vs binding to something from the matched object.
>
The constructor-like syntax for class patterns is the part I like least
about this proposal. It seems to expect that there is a one-to-one
correspondence between constructor arguments and instance attributes. While
that might be common, especially for DataClass-like types, it's certainly
not always the case. Some attributes might be computed from multiple
arguments (or looked up elsewhere), and some arguments may never be saved
in their original form. I fear it will be extremely confusing if an
attribute being matched by a class pattern doesn't correspond at all to an
argument in a valid constructor call. For example, this class would make
things very confusing:
class Foo:
def __init__(self, a, b):
self.c = a + b
You could match an instance of the class with `case Foo(c=x)` and it would
work, but that might come as a surprise to anyone familiar with the class
constructor's argument names.
Even when attributes and constructor arguments do line up, the class
pattern syntax also seems a bit awkward when you are not required to match
against all of the non-optional constructor arguments. I imagine `case
datetime.datetime(year=2020):` would be a valid (and even useful!) class
pattern, but you can't construct a datetime instance in that way since the
class has three required arguments.
To sum up, I feel like using constructor and keyword-argument syntax to
access attributes is an abuse of notation. I'd much prefer a new syntax for
matching classes and their attributes that was not so likely to be
confusing due to imperfect parallels with class construction.
_______________________________________________
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/7LXFWX5LPLJBRVUK7OEPB3KGJQNB3AO6/
Code of Conduct: http://python.org/psf/codeofconduct/
