On Sun, Jan 14, 2018 at 6:33 PM, Dima Tisnek wrote:
> Perhaps the latter is what `shield` should do? That is detach computation as
> opposed to blocking the caller past caller's deadline?
Well, it can't do that in trio :-). One of trio's core design
principles is: no detached processes.
And even
Hi,
On Thu, 11 Jan 2018 02:09:29 -0800
Nathaniel Smith wrote:
> Hi all,
>
> Folks here might be interested in this new blog post:
>
> https://vorpus.org/blog/timeouts-and-cancellation-for-humans/
>
> It's a detailed discussion of pitfalls and design-tradeoffs in APIs
> for timeout and cancell
Quick preface: there are definitely times when code "smell" really isn't --
nothing's perfect! -- and sometimes some system component is unavoidably
inelegant. I think this is oftentimes (but not always) the result of
scoping: clearly I couldn't decide, as a library author, that "it's all
just brok
On Sun, Jan 14, 2018 at 2:45 PM, Nick Badger wrote:
>> However, I think this is probably a code smell. Like all code smells,
>> there are probably cases where it's the right thing to do, but when
>> you see it you should stop and think carefully.
>
> Huh. That's a really good point. But I'm not su
On Sun, Jan 14, 2018 at 5:11 AM, Chris Jerdonek
wrote:
> On Sun, Jan 14, 2018 at 3:33 AM, Nathaniel Smith wrote:
>> On Fri, Jan 12, 2018 at 4:17 AM, Chris Jerdonek
>> wrote:
>>> Say you have a complex operation that you want to be able to timeout
>>> or cancel, but the process of cleanup / cance
I suppose the websocket case ought to follow conventions similar to kernel
TCP API where `close` returns immediately but continues to send packets
behind the scenes. It could look something like this:
with move_on_after(10):
await get_ws_message(url):
async def get_ws_message(url):
async
>
> However, I think this is probably a code smell. Like all code smells,
> there are probably cases where it's the right thing to do, but when
> you see it you should stop and think carefully.
Huh. That's a really good point. But I'm not sure the source of the smell
is the code that needs the sh
On Sun, Jan 14, 2018 at 3:33 AM, Nathaniel Smith wrote:
> On Fri, Jan 12, 2018 at 4:17 AM, Chris Jerdonek
> wrote:
>> Say you have a complex operation that you want to be able to timeout
>> or cancel, but the process of cleanup / cancelling might also require
>> a certain amount of time that you'
On Fri, Jan 12, 2018 at 4:17 AM, Chris Jerdonek
wrote:
> Thanks, Nathaniel. Very instructive, thought-provoking write-up!
>
> One thing occurred to me around the time of reading this passage:
>
>> "Once the cancel token is triggered, then all future operations on that
>> token are cancelled, so t
On Thu, Jan 11, 2018 at 7:49 PM, Dima Tisnek wrote:
> Very nice read, Nathaniel.
>
> The post left me wondering how cancel tokens interact or should
> logically interact with async composition, for example:
>
> with move_on_after(10):
> await someio.gather(a(), b(), c())
>
> or
>
> with move_o
Thanks, Nathaniel. Very instructive, thought-provoking write-up!
One thing occurred to me around the time of reading this passage:
> "Once the cancel token is triggered, then all future operations on that token
> are cancelled, so the call to ws.close doesn't get stuck. It's a less
> error-pron
Very nice read, Nathaniel.
The post left me wondering how cancel tokens interact or should
logically interact with async composition, for example:
with move_on_after(10):
await someio.gather(a(), b(), c())
or
with move_on_after(10):
await someio.first/race(a(), b(), c())
or
dataset =
Hi all,
Folks here might be interested in this new blog post:
https://vorpus.org/blog/timeouts-and-cancellation-for-humans/
It's a detailed discussion of pitfalls and design-tradeoffs in APIs
for timeout and cancellation, and has a proposal for handling them in
a more Pythonic way. Any feedback
13 matches
Mail list logo