On Oct 29, 2012, at 5:59 PM, Yury Selivanov
On 2012-10-29, at 12:07 PM, Antoine Pitrou
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@python.org http://mail.python.org/mailman/listinfo/python-ideas