[Python-ideas] Cofunctions - Back to Basics

[Greg Ewing]

On 27/10/11 15:53, Nick Coghlan wrote:

> 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.

That's why I've specified that the __cocall__ method can return
NotImplemented to signal that the object doesn't support cocalls.
When I say "implements __cocall__" I mean "has a __cocall__
method that doesn't return NotImplemented".

The prototype implementation makes use of this -- the only
difference between a function and a cofunction in that implementation
is a flag on the code object. The function object's __cocall__
method returns NotImplemented if that flag is not set.

> However, you still potentially have some pretty serious ambiguity
> problems - what happens inside an *actual* yield from clause? Or a for
> loop iterator expression?

There is no ambiguity. If f is a cofunction, then

    yield from f()

is equivalent to

    yield from (yield from f.__cocall__())

and

    for x in f():

is equivalent to

    for x in (yield from f.__cocall__()):

Both of these make sense provided that the return value
of f() is an iterable.

-- 
Greg