Oh sorry. I'm in too much of a hurry. :-(

The problem is that the thread may not have a loop, but the loop still has
a tread. E.g. the tests intentionally call set_event_loop(None) to make
sure that no code depends on the implict event loop. An app should be
allowed to do the same, even in debug mode.

IIUC this is already broken in debug mode? (Or perhaps only in non-main
threads?)

So in order to do correct diagnostics here we would have to add an "owning
thread" pointer to every event loop; then call_later() and friends can
check that the owning thread is the same as the current thread. But I'm not
sure that this is worth the work. (And I could see issues with the owning
thread concept as well.)

On Tue, Dec 16, 2014 at 4:21 PM, STINNER Victor <report@bugs.python.org>
wrote:
>
>
> STINNER Victor added the comment:
>
> 2014-12-17 0:53 GMT+01:00 Guido van Rossum <report@bugs.python.org>:
> > Well, the PEP clearly states that get_event_loop() should never return
> None
> > and raise an exception if the context has no environment. (Where context
> ~~
> > thread.)
>
> You don't reply to my question, or I misunderstood your anwer.
> call_soon() is a method an event loop, there is no need to call
> get_event_loop(). get_event_loop() is only called in debug mode to
> help the developer to detect obvious bugs. I don't think that the
> behaviour of the debug mode must be written in the PEP, it's more
> implementation specific.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue22926>
> _______________________________________
>