[Python-ideas] async: feedback on EventLoop API

[Shane Green]

Oh, I forgot error-backs.  True, though, error-handling is a bit more difficult.  I'm not sure I see it as being much more challenging that asynchronous callback error handling/reporting in general, though: it can still be executed in the exception context, etc.  And the chaining can even be used to attach extended error logging to all your callback chains, without losing or swallowing anything that wouldn't have been lost or swallowed by other approaches, unless I'm overlooking something. 





Shane Green 
www.umbrellacode.com
805-452-9666 | shane at umbrellacode.com

On Dec 18, 2012, at 7:51 PM, "Jasper St. Pierre" <jstpierre at mecheye.net> wrote:

> A lot of things become trivially easy if they assumption is that they can never fail.
> 
> Deferreds/Promises/Tasks/Futures are about sane error handling, not sane success handling.
> 
> (There's a few parts in the current proposal where this falls short, like par, but that's another post)
> 
> 
> On Tue, Dec 18, 2012 at 10:44 PM, Shane Green <shane at umbrellacode.com> wrote:
> Ignoring the API overlap with Futures/Promises for a moment, let me throw out this straw man approach to the event loop that seems to my naive eye like it pull together a lot of these ideas…
> 
> Rather than passing in your callbacks, factories, etc., asynchronous APIs return a lightweight object you register your callback with.  Unlike promises, deferrers, etc., this is a one-time thing: only one callback can register with it.  However, it can be chained.  The registered callback is invoked with the output of the operation when it completes.  
> 
> Timer.wait(20).then(callme, *args, **kw)
> # I could do 
> Timer.wait(20).then(callme, *args, **kw).then(piped_from_callme) 
> 
> #I could not do 
> handler = Timer.wait(20)
> handler.then(callme)
> handler.then(callme2) # this would throw an exception.
> 
> # I/O example…
> sock.accept().then(handle_connection) # invokes handle_connection(conn, addr)
> # Read some data
> conn.read(1024).then(handle_incoming) # handle_incoming invoked with up to 1024 bytes, read asynchronously.
> # Write some data
> conn.write("data").then(handle_written) # handle_written invoked with up number 5, giving number of bytes written async. 
> # Connect HTTP channel and add it to HTTP dispatcher.
> channel.connect((hostname,80)).then(dispatcher.add_channel)
> 
> 
> # Listen to FD's for I/O events
> descriptors.select(r, w, e).then(handle) # handle(readable, writables, oobs) 
> 
> It seems like only supporting a single callback per returned handle lets us circumvent a lot of the weight associated with normal promise/future/deferred pattern type implementations, but the chaining could come in handy as it may cover some of the use-cases being considered when multiple events per fd came up, plus chaining is pretty powerful, especially when it comes at little cost.  The API would be much more extensive than "then()", of course, with things like "every", etc. we'd have to pull examples from everything already discussed.  Just wanted to throw out there to get beat up about ;-) 
> 
> 
> 
> Shane Green 
> www.umbrellacode.com
> 805-452-9666 | shane at umbrellacode.com
> 
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
> 
> 
> 
> 
> -- 
>   Jasper
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121218/2e0778b3/attachment.html>