[Python-ideas] Cofunctions: It's alive! Its alive!
Nick Coghlan
ncoghlan at gmail.com
Wed Aug 11 04:48:05 CEST 2010
On Wed, Aug 11, 2010 at 10:49 AM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
>> - The syntax worries me. Your PEP suggests that cocall binds tightly
>> to an atom. That would mean that if the cofunction is really a
>> comethod, you'd have to parenthesis it,
>
> No, if you examine the grammar in the PEP you'll see that
> the atom can be followed by a subset of the trailers allowed
> after atoms in other contexts, so it's possible to write
> things like
>
> x = cocall foo.blarg[42].stuff(y)
>
> which parses as
>
> x = cocall (foo.blarg[42].stuff)(y)
I would expect the grammatical rules for cocall expressions to be
similar to those for yield expressions. And if they weren't, I'd want
to hear a really good excuse for the inconsistency :)
Also, a possible trick to make a @cofunction decorator work:
class cofunction:
# Obviously missing a bunch of stuff to tidy up the metadata
def __init__(self, f):
self._f = f
def __cocall__(*args, **kwds):
self, *args = *args
return yield from self._f(*args, **kwds)
Cofunctions then wouldn't even *have* a __call__ slot, so you couldn't
call them normally by mistake, and ordinary functions wouldn't define
__cocall__ so you couldn't invadvertently use them with the new
keyword.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas
mailing list