On Sat, 9 Jan 2021 12:17:32 +0000 Paul Moore <p.f.moore@gmail.com> wrote:
On Sat, 9 Jan 2021 at 10:52, Paul Sokolovsky <pmiscml@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". Regards Antoine.