Hello,
On Sun, 3 Jan 2021 16:50:33 +0000
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.
>
> 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"? 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.
>
> 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".
> It abandons any idea of "make matching look like the thing that's
> being matched" and replaces it with a completely new set of syntax,
> which lacks the intuitive nature that I expect from Python
+1 for that evaluation. And I'd like to remind with what the original
discussion started, with very simple and focused questions:
a) What if we *do* use sigils for value patterns?
or,
b) What if we *do* use sigils for capture patterns?
Instead of focusing on one of the above questions, making fine,
focused, pin-head sized adjustments to the original pattern matching
PEPs, with PEP642 we've got a noticeable scope creep, with evermore
extravagant syntax replacements of the large part of the original
proposal.
This once again shows that it's very easy to get carried away and how
important for others to help to remind where to stop.
[]
> I have not read the full PEP, so take this as very much a "first
> impression" reaction, 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.
Just the same, there's no need to go too far here either. The question
of PEP642 rejection should be treated as orthogonal to acceptance /
rejection of PEP634. Because, well, PEP634 misses to do some things
better, but indeed at least some of them can be added later. But PEP642
twists matters so much, that it likely will be irreparable afterwards.
>
> Paul
--
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/GBKFB54YFUY3Y6PC5BXYNMTD6NDEAZPG/
Code of Conduct: http://python.org/psf/codeofconduct/
