Hello,
On Sat, 9 Jan 2021 14:49:19 +0100
Antoine Pitrou <anto...@python.org> wrote:
> On Sat, 9 Jan 2021 12:17:32 +0000
> Paul Moore <p.f.mo...@gmail.com> wrote:
>
> > 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.
>
> Introducing a new syntax is not a problem, it's the solution. The
> problem with PEP 634 is precisely that it reuses existing syntax and
> gives it a different meaning, thereby producing confusion.
>
> It's erroneous to claim that `{"host" as host, "port" as port}` is a
> set. It's currently invalid syntax due to the `as`:
>
> >>> {"host" as host, "port" as port}
> File "<stdin>", line 1
> {"host" as host, "port" as port}
> ^
> SyntaxError: invalid syntax
>
>
> So, opposing Nick's proposal on the basis that it "looks like a set"
> is just like opposing set literals on the basis they they "look like a
> dict".
No, it's different kind of opposition. Consider for example the syntax
"2+2". One can say that it doesn't make sense, everyone knows that two
plus two is four, so everyone would write "4" right away. So, let's
take "2+2" and assign to it a different meaning, let's say that it means
"5". Or let's say that it means a dict.
That's exactly what PEP642 does - it takes set *syntax* and
appropriates it for dict *semantics*, hence the opposition. Compare
that to what PEP634 does: it takes tuple syntax, and defines sequence
pattern matching based on it; it also takes dict syntax and defines
mapping pattern matching based on it; finally, it takes object
construction syntax, and defines object pattern matching syntax based
on it.
In all 3 cases, PEP634 defines *new semantics* based on *existing
syntax* (by putting it into new higher-level syntactic construct, the
"case" clause), and does so in consistent way. PEP634 later could be
extended with set patterns, e.g.:
match [1, 2]:
case {1, 2}: # matches
match [1, 2]:
case {2, 1}: # also matches
match {1, 2}:
case {2, _ as another}: # matches and assigns 1 to 'another'
Whereas again, PEP642 tries to appropriate such set pattern syntax for
completely different purpose, only because its author thought that it's
ok in the mapping pattern syntax to suddenly drop ":" operator.
--
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/4AHGIRAYYMXCRXLGCDUG44C46KDMBA4K/
Code of Conduct: http://python.org/psf/codeofconduct/
