On Fri, Oct 30, 2020 at 6:39 PM Tin Tvrtković wrote:
> A small update on this, since I've been playing with it.
>
> I'm trying to implement a websocket proxy, since it's an example of a toy
> project that needs to juggle two long-lived asyncio connections at once.
> I'm using Starlette/Uvicorn
Hello,
On Sat, 31 Oct 2020 18:53:57 +1000
Nick Coghlan wrote:
> On Sat, 31 Oct 2020 at 18:20, Paul Sokolovsky
> wrote:
> > I blame it on my Saturday's hazy mind, but also for the interest of
> > other readers, could you elaborate on "`==` interacts poorly with
> > other aspects of the pattern
On Sat, 31 Oct 2020 at 18:20, Paul Sokolovsky wrote:
> I blame it on my Saturday's hazy mind, but also for the interest of
> other readers, could you elaborate on "`==` interacts poorly with other
> aspects of the pattern syntax"?
Class patterns use the keyword argument syntax to match by
Hello,
On Sat, 31 Oct 2020 18:01:16 +1000
Nick Coghlan wrote:
> On Sat, 31 Oct 2020 at 17:49, Paul Sokolovsky
> wrote:
> > Alternatively, can add "inline guard sigils" for the most common
> > guard conditions, which would be equality, period:
> >
> > match r:
> > case (src, None):
> >
On Sat, 31 Oct 2020 at 17:49, Paul Sokolovsky wrote:
> 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):
`==` interacts poorly with other aspects
Hello,
On Sat, 31 Oct 2020 02:37:14 +0100
Tin Tvrtković 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 =
A small update on this, since I've been playing with it.
I'm trying to implement a websocket proxy, since it's an example of a toy
project that needs to juggle two long-lived asyncio connections at once.
I'm using Starlette/Uvicorn for the server part (the part that accepts the
connection) and
Hello,
Go channels are indeed very similar to asyncio Queues, with some added
features like channels being closable. (There is also special syntax in the
select statement, `val, ok <- chan`, that will set the `ok` variable to
false if the channel has been closed.) A larger difference, I think, is
It's true that asyncio.wait provides the tools that you need, but it's a
bit clunky to use correctly.
Maybe would be something along the lines of:
--
queue1 = asyncio.Queue()
queue2 = asyncio.Queue()
...
get1 = asyncio.create_task(queue1.get())
get2 = asyncio.create_task(queue2.get())
await
On Sat., 24 Oct. 2020, 4:21 am Guido van Rossum, wrote:
> On Fri, Oct 23, 2020 at 6:19 AM Tin Tvrtković
> wrote:
>
>> Hi,
>>
>> first of all, I'm a big fan of the changes being proposed here since in
>> my code I prefer the 'union' style of logic over the OO style.
>>
>> I was curious, though,
Woah, this is both exciting and scary. If adopted, it will be a major
change to how Python programs are written. It seems a lot of work has
been put into polishing the design. That's good because if we do this,
will not be easy to fix things later if we made design errors.
One of my first
On Fri, Oct 23, 2020 at 6:19 AM Tin Tvrtković wrote:
> Hi,
>
> first of all, I'm a big fan of the changes being proposed here since in my
> code I prefer the 'union' style of logic over the OO style.
>
> I was curious, though, if there are any plans for the match operator to
> support async
Hi,
first of all, I'm a big fan of the changes being proposed here since in my
code I prefer the 'union' style of logic over the OO style.
I was curious, though, if there are any plans for the match operator to
support async stuff. I'm interested in the problem of waiting on multiple
asyncio
On Thu, Oct 22, 2020 at 09:48:54AM -0700, Guido van Rossum wrote:
> After the pattern matching discussion died out, we discussed it with the
> Steering Council. Our discussion ended fairly positive, but there were a
> lot of problems with the text. We decided to abandon the old PEP 622 and
> break
On Thu, Oct 22, 2020 at 10:42 AM MRAB wrote:
> [Guido]
> > - SyntaxError if an irrefutable case[1] is followed by another case
> block.
> > - SyntaxError if an irrefutable pattern[1] occurs on the left of '|',
> > e.g. 'x | [x]'.
>
> Is "syntax error" that the right term for it? Maybe it should
On 2020-10-22 17:48, Guido van Rossum wrote:
After the pattern matching discussion died out, we discussed it with the
Steering Council. Our discussion ended fairly positive, but there were a
lot of problems with the text. We decided to abandon the old PEP 622 and
break it up into three parts:
16 matches
Mail list logo
