Guido van Rossum added the comment: 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 <rep...@bugs.python.org> wrote: > > > STINNER Victor added the comment: > > 2014-12-17 0:53 GMT+01:00 Guido van Rossum <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue22926> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22926> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com