[Python-Dev] PEP 492: What is the real goal?

[Jim J. Jewett]

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