[Python-ideas] An async facade?

[Jasper St. Pierre]

Note that the "return b" is already being handled through the
"StopIteration" proposal.

I'm not a fan of the new syntax because it means that removing all the
"await" keywords from a method changes the return value. Requiring the
decorator means that this can cleanly be handled in all cases, even if the
decorator implementation is a bit ugly.

This means that all we have left is the "await" vs. "yield" vs. "yield
from" discussion. I don't think the new valuable enough to warrant a new
keyword.



On Thu, Dec 20, 2012 at 5:52 PM, Jonathan Slenders <jonathan at slenders.be>wrote:

> Hi All,
>
> This week I finished some Python syntax on a Pypy fork. It was an
> experiment I was working on this week. We really needed a cleaner way of
> writing asynchronous code. So, instead of using the yield keyword and an
> @async decorator, we implemented the 'await' keyword, similar to c#.
>
> So, because I just now subscribed to python-ideas, I cannot reply
> immediately to the following thread:
>
> An async facade? (was Re: [Python-Dev] Socket timeout and completion based
> sockets)
>
>
> Anyway, like c# does, I implemented the await keyword for Python, and
> should say that I'm really confident of the usability of the result. Personally,
> I think this is a very clean solution for Twisted's @defer.inlineCalbacks,
> Tornado's @gen.engine, and similar functions in other async frameworks. We
> use it right now in a commercial web environment, where third party users
> should have to be able to write asynchronous code as easy as possible in a
> web based IDE.
>
> https://bitbucket.org/jonathanslenders/pypy
>
> Two interpreter hooks were added: (both accept a callable as parameter.)
>
> >>>> sys.setawaithandler(wrapper)
> >>>> sys.setawaitresultwrapper(result_wrapper)
>
>
> The first will set the I/O scheduler  a functions for wrapping others
> functions which contain 'await' instead of 'yield'. This wrapper function
> will receive a generator as input. So, 'await' still acts like 'yield' for
> the interpreter, but the result is automatically wrapped by this function,
> if the await keyword was found.
>
> The second function will wrap the return result of asynchronous functions.
> So, unlike normal generators with 'yield' keywords, where 'await' has been
> used, we still can return a result. But this result will be wrapped by this
> function, so that the generator in the scheduler  will be able
> te recognize the returned result.
>
> This:
>
> @defer.inlineCallbacks
> def async_function(deferred_param):
>     a = yield deferred_param
>     b = yield some_call(a)
>     yield defer.returnValue(b)
>
>
> will now become:
>
> def async_function(deferred_param):
>     a = await deferred_param
>     b = await some_call(a)
>     return b
>
>
> So, while still being explicit, it requires minimal syntax, and
> allows distinguishing between when to 'wait' for an asynchronous task, and
> when to pass the Future object around.
>
> I really have no idea whether this has been proposed before, I can only
> say that we are using it and it works pretty well.
>
> Cheers,
> Jonathan
>
>
>
> _______________________________________________
> 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/20121220/3160b2e3/attachment.html>