> On Feb 12, 2015, at 8:39 AM, Andrew Svetlov <[email protected]> wrote: > > I'm with Ben Darnell: coroutine decorator is more like classmethod > than return type.
For what it's worth, I disagree; a coroutine is something that a method either returns or doesn't return, so it is more like return type than classmethod because it literally is return type :). It's a parametric type, though. In the same way that you never really have just "list", you have "list of X", with coroutines you don't simply have "coroutine", you have "coroutine[returning X / raising Y]". Twisted's nomenclature for this is "Deferred[firing with X / failing with Y]"; our documentation tooling around it has never really been there, which is a bit sad, but you pretty much have to describe it in a similar way to return type, because it does modify the return type. The problem with the language of "coroutine" is that really, the methods themselves are coroutines, so the things that they return, or the "instances" of them are... Future-alike or something? Asynchronously iterable? I haven't seen good nomenclature anywhere which unifies thing-which-may-be-yielded-from. (Which is, I guess, what this thread is about, after all...) -g
