From: Joe E. <jen...@fl...> - 2012-02-13 18:13:59
|
Andreas Leitgeb wrote: > There is one thing, I find even goofier than having *all* the > yield... commands return a list of multiple arguments: > namely have one of them do, and the other not do, based on > some otherwise orthogonally different functionality they > perform. With this TIP, there are only two yield... commands: [yieldto], which is the general-purpose, low-level primitive, and (the existing) [yield], which can be seen as a convenience routine for the most common usage pattern. > Is it possible to have "coroutine" create single-arg coroutines > while some new "mcoroutine" would create multi-arg coroutines, > and yield and yieldto would behave consistently for each? That > is: both returning the single arg for a coro, and both returning > the list of the args for an mcoro ? I do not like that idea. That would mean that the return value of [yield] and [yieldto] depend on nonlocal information. > That would avoid the absolutely unnecessary complication of > the resumption command for a coroutine changing its signature > appearantly randomly (from outside-view). So don't do that :-) The number and meaning of the arguments accepted by the resumption command already depends on the state of the coroutine. This TIP doesn't change that, except that now instead of "zero or one" arguments the resumption command can accept "zero or more". --Joe English jen...@fl... |