[Python-ideas] Cofunctions: It's alive! Its alive!

ghazel at gmail.com ghazel at gmail.com
Tue Aug 10 14:45:34 CEST 2010

On Tue, Aug 10, 2010 at 5:10 AM, Jack Diederich <jackdied at gmail.com> wrote:
> On Tue, Aug 10, 2010 at 3:22 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> Guido van Rossum wrote:
>>> We'll see. I still cannot get my head around why cofunctions are so
>>> great.
> [snip]
>> Here's the equivalent thing using cofunctions, complete with a
>> corresponding missing 'cocall':
> [snip]
>> The exception and traceback resulting from this is crystal clear:
>> Traceback (most recent call last):
>>  File "restaurant2.py", line 34, in <module>
>>    run()
>>  File
>> "/Local/Projects/D/Python/YieldFrom/3.1/Cofunctions-3.1.2/Examples/Simulation/simulation.py",
>> line 25, in run
>>    next(current_process)
>>  File "restaurant2.py", line 29, in customer
>>    hold(random.normalvariate(10, 5))
>> TypeError: Cofunction must be called with cocall or costart
>> If this doesn't convince you of the utility of cofunctions or
>> something like them, I don't know what will.
> So the benefit of cocalls is runtime type checking? Are your unit tests broken?

Not entirely. I think "cocall" is a better term than "yield from" for
this task, and I see benefit in having an explicit way to declare a
cofunction, instead of the "if 0: yield" trick. The runtime type
checking benefits are certainly helpful, though, even if all they do
is make it clear why your unit tests are failing.

> I was -0 on ABCs and function annotations because I was promised by
> people that liked them that I could safely ignore them.  I can't
> safely ignore this so I'm -1.

How were you hoping to ignore them? You can't safely ignore yield or
generators, either. If a function you are calling which returned a
list decided to change its implementation and be a generator, then
your list subscript access would stop working, since generators are
not subscriptable.


More information about the Python-ideas mailing list