On 2011-11-02 10:54, Greg Ewing wrote:
Nick Coghlan wrote:
However, as per the previous thread, I don't believe this needs to be embedded in the bytecode by the compiler - it could instead be a runtime switch in the eval loop, changing the way function calls and iteration are handled.
Yes, but I'm no longer sure whether it's such a good idea to have no special syntax at all to mark a cofunction, seeing as cofunctionness won't be able to propagate through C calls, special methods, etc.
By having cofunctions declared in a distinctive way, you can look at the source and see exactly where the boundary is between cofunction and non-cofunction code. Without such markers, when you get an exception because you tried to suspend in a non-coroutine zone, it may not be obvious at which point along the call chain you made a mistake.
If the switch Nick describes is available as a flag on the frame objects, it would be easy to extend the traceback to show *exactly* where you entered the no-coroutine zone that you are now failing to suspend. I don't think the additional syntax is helpful, and it would be quite annoying to need to have two versions of every wrapper function/decorator to make it useable in both contexts.