On Thu, Oct 27, 2011 at 12:09 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
So, I've gone right back to my initial idea. The current version of the draft PEP can be found here:
http://www.cosc.canterbury.ac.nz/greg.ewing/python/generators/cd_current/cof...
---------- Certain objects that wrap other callable objects, notably bound methods, will be given __cocall__ implementations that delegate to the underlying object. ---------- That idea doesn't work when combined with the current idea in the PEP for implicit cocall support inside cofunction definitions. Simple method calls will see "Oh, this has __cocall__" and try to treat it like a cofunction, when the underlying object is actually an ordinary callable. To make it work, you'll need some kind of explicit conversion API (analogous to __iter__). Then, the expansion of calls in a cofunction would look something like: _cofunc = obj.__cofunction__() if _cofunc is None: result = obj.__call__(*args, **kwds) else: result = yield from _cofunc(*args, **kwds) However, you still potentially have some pretty serious ambiguity problems - what happens inside an *actual* yield from clause? Or a for loop iterator expression? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia