On Fri May 1 23:58:26 CEST 2015, Yury Selivanov wrote:
Yes, you can't use 'yield from' in __exit__/__enter__ in current Python.
What do you mean by "can't use"?
It probably executed without errors, but it didn't run the generators.
True. But it did return the one created by __enter__, so it could be bound to a variable and iterated within the block. There isn't an easy way to run the generator created by __exit__, and I'm not coming up with any obvious scenarios where it would be a sensible thing to do (other than using "with" on a context manager that *does* return a future instead of finishing). That said, I'm still not seeing why the distinction is so important that we have to enforce it at a language level, as opposed to letting the framework do its own enforcement. (And if the reason is performance, then make the checks something that can be turned off, or offer a fully instrumented loop as an alternative for debugging.)
Is the intent to do anything more than preface execution with: import asynchio.coroutines asynchio.coroutines._DEBUG = True
If you enable it after you import asyncio, then asyncio itself won't be instrumented.
Why does asynchio itself have to wrapped? Is that really something normal developers need to debug, or is it only for developing the stdlib itself?
Yes, normal developers need asyncio to be instrumented, otherwise you won't know what you did wrong when you called some asyncio code without 'await' for example.
I'll trust you that it *does* work that way, but this sure sounds to me as though the framework isn't ready to be frozen with syntax, and maybe not even ready for non-provisional stdlib inclusion. I understand that the disconnected nature of asynchronous tasks makes them harder to debug. I heartily agree that the event loop should offer some sort of debug facility to track this. But the event loop is supposed to be pluggable. Saying that this requires not merely a replacement, or even a replacement before events are added, but a replacement made before python ever even loads the default version ... That seems to be much stronger than sys.settrace -- more like instrumenting the ceval loop itself. And that is something that ordinary developers shouldn't have to do. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ