Hello,
On Sat, 9 Jan 2021 14:49:19 +0100
Antoine Pitrou
On Sat, 9 Jan 2021 12:17:32 +0000 Paul Moore
wrote: On Sat, 9 Jan 2021 at 10:52, Paul Sokolovsky
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:pmiscml@gmail.com