Re: [Async-sig] Blog post: Timeouts and cancellation for humans

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

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

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

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

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

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

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

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

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

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

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):

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

> > 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

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

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

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

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

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

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()) > >

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

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 >

[Async-sig] Blog post: Timeouts and cancellation for humans

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