On Mon, 4 Jan 2021, 2:50 am Paul Moore, <p.f.mo...@gmail.com> wrote:
> On Sun, 3 Jan 2021 at 16:26, Barry Scott <ba...@barrys-emacs.org> wrote:
> > I read the above and believe I know what it meant without needing to
> read the PEP in detail.
> > I like that a lot.
>
> Personally, I read it and was horribly confused. I worked out most of
> it, but I would *not* count it as intuitive or natural.
>
> Specific examples:
>
> case {"host" as host, "port" as port}:
> pass
> case {"host" as host}:
> pass
>
> I assume that's dictionary unpacking? It doesn't really look like
> anything else in Python, though, and it took me a while to work out.
>
These *can* have the colon included, and it would be quite viable to have
that as the only spelling in the initial design iteration:
case {"host": as host, "port": as port}:
pass
case {"host": as host}:
pass
The submitted grammar just allows the colon to be left out for brevity (as
even with it missing you were still able to correctly identify this as a
mapping match).
> case object{.host as host, .port as port}:
> pass
>
> I can only guess at this. I assume "subclass of object with host and
> port attributes/properties"?
Correct :)
But why use {...} for object access? And
> does that extend to Foo{...} meaning "subclass of Foo? There's no
> reason to assume yes or no to that.
>
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.
By contrast, "object{.host, .port}" is currently illegal syntax that could
plausibly become a syntactic shorthand for "(object.host, object.port)" in
both ordinary expressions and in assignment targets, even if it was
initially only supported in pattern matching.
> Overall, the whole thing feels like an attempt to invent some sort of
> syntax in reaction to the PEP 634 form - not having a logic in its own
> right, but simply with a driving principle of "don't be like PEP 534".
>
The design logic went as follows:
1. Start with PEP 634
2a. Ensure all "binding to the right" operations use 'as'
2b. Ensure all bare names outside subexpressions are qualified with a sigil
or keyword
3. Ensure all deconstruction operations offer a potential future path to
producing tuples in ordinary expressions using pattern matching inspired
syntax
It abandons any idea of "make matching look like the thing that's
> being matched"
PEP 634 doesn't offer that for class patterns either.
I like being able to leave out the colon for mapping name bindings, but
wouldn't object to requiring that it be left in.
and replaces it with a completely new set of syntax,
> which lacks the intuitive nature that I expect from Python (and yes, I
> know that can be read as "I'm not familiar with it, so I don't like
> it" - that may indeed be all that it is, but I feel that it's a bit
> more fundamental than just that).
>
> I have not read the full PEP, so take this as very much a "first
> impression" reaction,
I'd definitely like to hear your second impression after reviewing the PEP
text, but getting first impressions like yours was a big part of my
motivation for including the match statement example.
but I'd avoid using this syntax, both in my own
> projects and in any project I contribute to. Honestly, I feel like I'd
> rather see pattern matching rejected altogether than see this version
> accepted.
>
I've reached that point with PEP 634 - I think the problems with binding to
the right in mapping and especially class patterns are serious enough that
I'd prefer to see no pattern matching to *that* syntax for pattern matching.
I also have concerns about AST ambiguity in the current PEP 634
implementation, but those could be fixed by defining separate AST nodes for
patterns without having to change the surface syntax proposal (the AST I've
defined for 642 should be usable for 634 as well).
Cheers,
Nick.
> Paul
>
_______________________________________________
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/VV3XFMBY4ZKGAOA4QJY3PGKQK4GUQRKS/
Code of Conduct: http://python.org/psf/codeofconduct/
