[Python-ideas] Async API: some code to review
rene at stranden.com
Mon Oct 29 23:23:34 CET 2012
On Oct 29, 2012, at 5:59 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> On 2012-10-29, at 12:07 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> In the docstrings I use the prefix "COROUTINE:" to indicate public
>>> APIs that should be invoked using yield from.
>> Hmm, should they? Your approach looks a bit weird: you have functions
>> that should use yield, and others that should use "yield from"? That
>> sounds confusing to me.
>> I'd much rather either have all functions use "yield", or have all
>> functions use "yield from".
>> (also, I wouldn't be shocked if coroutines had to wear a special
>> decorator; it's a better marker than having the word COROUTINE in the
>> docstring, anyway :-))
> That's what bothers me is well. 'yield from' looks too long for a
> simple thing it does (1); users will be confused whether they should
> use 'yield' or 'yield from' (2); there is no visible difference between
> a plain generator and a coroutine (3).
I agree, was this ever commented ? I know it maybe late in the discussion
but just because you can use yield/yield from for concurrent stuff, should you?
it looks very implicit to me (breaking the second rule)
Have the delegate/event model of C# been discussed ?
As always i recommend moving the concurrent stuff to the object level, it
would be so much easier to state that a message for an object is just that:
An async message sent from one object to another… :-)
A simple decorator like @task would be enough:
@task # explicit run instance in own thread/coroutine
def asyc_add(self, x, y)
return x + y # returns a Future() with result
task = SomeTask()
n = task.async_add(2,2)
# Do other stuff while waiting for answer
print( "result is %d" % n ) # Future will wait/hang until result is ready
> Personally, I like Greg's PEP 3152 (aside from 'cocall' keyword).
> With that approach it's easy to distinguish coroutines, generators and
> plain functions. And it'd be easier to add some special
> methods/properties to codefs, like 'in_finally()' method etc.
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas