[Python-Dev] async/await in Python; v2 (original) (raw)
Greg Ewing greg.ewing at canterbury.ac.nz
Thu Apr 23 12:29:19 CEST 2015
- Previous message (by thread): [Python-Dev] async/await in Python; v2
- Next message (by thread): [Python-Dev] async/await in Python; v2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Yury Selivanov wrote:
So you would have to write 'await fut()'? This is non-intuitive.
That's because PEP 492 and its terminology encourage you to think of 'await f()' as a two-step process: evaluate f(), and then wait for the thing it returns to produce a result.
PEP 3152 has a different philosophy. There, 'cocall f()' is a one-step process: call f and get back a result (while being prepared to get suspended in the meantime).
The two-step approach has the advantage that you can get hold of the intermediate object and manipulate it. But I don't see much utility in being able to do that.
Keep in mind that you can treat cofunctions themselves as objects to be manipulated, just like you can with ordinary functions, and all the usual techniques such as closures, * and ** parameters, etc. are available if you want to encapsulate one with some arguments.
About the only thing you gain from being able to pass generator-iterators around instead of the functions that produce them is that you get to write
t = Task(func(args))
instead of
t = Task(func, args)
which seems like a very minor thing to me. I would even argue that the latter is clearer, because it makes it very obvious that the body of func is not executed before the Task is constructed. The former makes it look as though the result of executing func with args is being passed to Task, rather than func itself.
-- Greg
- Previous message (by thread): [Python-Dev] async/await in Python; v2
- Next message (by thread): [Python-Dev] async/await in Python; v2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]