[Python-ideas] Async API: some code to review

[Rene Nejsum]

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
class SomeTask(object):
  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


br
/rene

> 
> 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.
> 
> -
> Yury
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas