
On Tue, Aug 10, 2010 at 5:10 AM, Jack Diederich <jackdied@gmail.com> wrote:
On Tue, Aug 10, 2010 at 3:22 AM, Greg Ewing <greg.ewing@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. -Greg