On Tue, Aug 10, 2010 at 7:48 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Wed, Aug 11, 2010 at 10:49 AM, Greg Ewing <greg.ewing@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 :)
This I can explain -- a cocall *must* be a call, syntactically, so that it can take the callable, check that it has a __cocall__ method, and call it with the given argument list. But I have to say, I don't really like it, it's very odd syntax (even worse than decorators).
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@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)