On Mon, 4 Jan 2021 at 18:38, Paul Moore <p.f.mo...@gmail.com> wrote:
>
> On Sun, 3 Jan 2021 at 23:38, Nick Coghlan <ncogh...@gmail.com> wrote:
> >
> > The instance attribute syntax arose from trying to deal with two problems
> > from class patterns in PEP 634:
> >
> > * "ATTR=TARGET" using "=" to bind to the right instead of to the left
> > * no subsequent path to ever offering a syntax for *retrieving* multiple
> > attributes in ordinary expressions outside pattern matching
> >
> > The minimal fix for the first point would have been just "case
> > object(host=as host, port=as port}:", but that couldn't ever be used to
> > retrieve multiple attributes, as "object(host, port)" is already a function
> > call.
>
> OK, so there's our dispute. Neither of those seem to me to be problems
> with PEP 634.
>
> 1. I view ATTR=PLACEHOLDER as *equality* with a placeholder that gets
> filled in, not a binding that goes left to right. (And no, I don't
> have a problem with the rule that the placeholder must be on the
> right).
But why would you assume `=` means that in Python code? The only
places we currently use `=` are in assignment statements and in
keyword arguments, and in both of those cases, the target is on the
left:
TARGET = EXPR
func(TARGET_PARAM=EXPR)
However, you're right, if "SOURCE = DESTINATION" doesn't read
strangely to you, then the switch to mapping-pattern inspired syntax
for attribute patterns in PEP 642 isn't going to feel compelling.
For the other point, consider the following examples (using "match
SUBJECT as case PTRN" as a strawman one-shot pattern matching syntax):
# One shot PEP 634 pattern
match addr as case object(host=host, port=port)
# One shot PEP 642 pattern
match addr as case object{.host as host, .port as port}
# Attribute tuple (PEP 642 based deferred idea)
host, port = addr{.host, .port}
One shot pattern matching turns out to have an inherent verbosity
problem, as it forces the specification of the destructuring to be
separated from the specification of the subject. That separation is
desirable in match statements, where one subject is potentially
destructured in different ways. It's far from clear that the
separation would be desirable in one-shot matching - we might instead
be better off with a model that only allows simple destructuring
operations that produce a tuple, and then uses ordinary iterable
unpacking for name binding.
While that's a relatively minor point in the grand scheme of things, I
do like having more future design options available to us.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
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/XJZQDW44LVCHCUSH4BSO3BWADRBORC4K/
Code of Conduct: http://python.org/psf/codeofconduct/
