Bruce Leban wrote:
The only special consideration is that 'codef' must be used to define any function that directly or indirectly calls another cofunction.
It seems to me that this is a big requirement. If a module that I'm using uses cofunctions, then every use of that module must be a cofunction all the way up to my main function.
Well, at least all the way up to the coroutine scheduler or driver or whatever you want to call it. That statement is actually a bit abbreviated. The caller doesn't strictly have to be a cofunction, but if it's not, it has to be aware that the called cofunction is a generator and deal with it as such, for example by using 'yield from' (which in turn makes the caller a generator) or by looping over it (in which case the caller can be an ordinary function). However you arrange things, there has to be an unbroken chain of generators from the main loop driving the coroutines down to the functions containing the yields. The only question is whether to mark them as such at the function level (using 'codef') or at the call site level (using 'yield from').
Worse, I wouldn't be able to change the implementation of a module to use cofunctions because it will break the current users.
There would be nothing to stop a module from using cofunctions internally, as long as it runs its own driver loop and presents its outside interface in the form of ordinary functions that run to completion. But if it exposes any cofunctions directly to its users, they will need to be aware of the fact, just as they need to be aware of an exposed function that is a generator. -- Greg