On Sat, 9 Jan 2021 at 10:52, Paul Sokolovsky <pmis...@gmail.com> wrote:
> > case {"host" as host, "port" as port}:
>
> There're 2 obvious problems with it:
>
> a) In Python, {} with things inside it, but no ":" inside it, is a set,
> set.
> b) Everywhere else in Python, thing on the left of "as" gets into
> thing on the right of "as", behold:
>
> import foo as bar # original module "foo" gets into "bar".
> with Cls(a, b) as c: # original expression "Cls(a, b)" gets into "c"
>
> Then based on the existing Python syntax, the meaning of '{"host" as
> host, "port" as port}' is: a set, whose contained, constant in this
> case, values "host" and "port" get captured as variables host and port.
> In pattern matching context (with 'case' in front), it means: match
> using a set, check for presence on constant "host" and "port" elements,
> and capture those constants to variables host and port (that
> capturing doesn't make much sense, yeah. And yet syntax tells just
> that. You propose to assign to it completely different meaning.).
This analysis nicely captures my reservations with the proposal here.
It claims to be addressing the problems with PEP 634, where the syntax
proposed there is specialised to matching, but it then proceeds to
introduce another syntax, which is *also* unlike existing usage, just
in different ways.
You may say that the PEP 642 syntax is "better", but that's a matter
of opinion. Having {...} without a colon be a dict-style unpacking is
very uncomfortable to me. Having "as" not assign the result of what's
on the left of it to the right hand name is uncomfortable to me. The
PEP 634 equivalents do *not* feel uncomfortable in the same way.
I'm mostly just repeating myself here, though. I'm on record already
as saying that I feel PEP 642 is strictly worse than PEP 634. My main
worry is that the two competing PEPs turn the question into "let's
assume pattern matching is a good thing, which is the better syntax" -
which is *not* the question. Each PEP should be considered on its own
merits, and people who like pattern matching but don't like the PEP
634 syntax should be *at least* as strict in their analysis of PEP 642
(possibly even more so, because PEP 642 makes a bunch of unverified -
and in my view, unjustified - assumptions about the desirability of
potential adoption of the syntax in wider contexts).
To be honest, though, I think that we're now at the point where we
have to rely on the SC for a decision. Pretty much everyone has made
their views clear, so the final decision is going to be down to
"design instinct". Ultimately, that's the basis on which we all voted
for SC members, after all.
Paul
PS This situation is particularly special, of course, because it's a
direct comparison of Guido's design instincts (PEP 634) and the SC's.
So whatever the result, it'll be interesting!
_______________________________________________
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/2FZFQMBHDBELMQJRMC526OV2UQ5N4QSU/
Code of Conduct: http://python.org/psf/codeofconduct/
