Hello,

On Sat, 31 Oct 2020 02:37:14 +0100
Tin Tvrtković <tinches...@gmail.com> wrote:

[]


> async def ws_proxy(client: WebSocket):
>     await client.accept()
>     async with ClientSession() as session:
>         async with session.ws_connect("wss://echo.websocket.org") as
> s: c = starlette_websocket_iterator(client)
>             async for r in wait_on(c, s):
>                 match r:
>                     case (src, None):
>                         print(f"{src} closed the connection")
>                         break
>                     case (src, msg) if src is c:
>                         print(f"CLIENT: {msg}")
>                         await s.send_str(msg)
>                     case (src, msg) if src is s:
>                         print(f"SERVER: {msg}")
>                         await client.send_text(msg.data)
> 
> So yeah, the helper yields tuples of the source and message, using
> None as a sentinel for closure. Guards are used to match on the
> source, using iterator identity.


> My first version just used `case (s, msg):` hoping to match on the
> identity of s, but that doesn't work since s is not a literal.
> 
> ..., I'd say
> this style of programming is quite readable and understandable.

It baffled me how the first sentence contradicts the second.


So, with Mark Shannon's recent (re)criticism of pattern matching PEP,
in particular "Can pattern matching make it clear what is assigned?" 
anyone wants to go 2nd round on "sigils aren't that bad,
especially comparing to what we're offered otherwise"?


E.g. would it really be that bad to have: 

match r:
    case (@src, None):
    case (c, @msg):
    case (s, @msg):

Alternative syntax, arguably, even newbie can pick it up what it does:

match r:
    case (>src, None):
    case (c, >msg):
    case (s, >msg):
 
Alternatively, can add "inline guard sigils" for the most common guard
conditions, which would be equality, period:

match r:
    case (src, None):
    case (==c, msg):
    case (==s, msg):


[]

-- 
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/FDSJOO6KLGSW7SAGBR4W2KHKHBVKVETB/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to