Vincent Michel added the comment:
I agree with Yury's ideas about the implementation of this feature. However, it
is a bit confusing to have `asyncio.get_event_loop` defined as:
def get_event_loop():
policy = get_event_loop_policy()
return policy.get_running_loop() or policy.get_event_loop()
One would expect `asyncio.get_event_loop` to simply work as a shortcut for:
get_event_loop_policy().get_event_loop()
The root of the problem is that we're trying to define 3 concepts with only 2
wordings. I think it is possible to solve this issue quite easily by renaming
`AbstractLoopPolicy.get_event_loop` with `AbstractLoopPolicy.get_default_loop`.
We'd end up with the following definitions:
- default_loop: current default loop as defined in the policy
- running_loop: current running loop (thread-wise) if any
- event_loop: running loop if any, default_loop otherwise
Changing the API is always annoying, but in this case it would only affect the
event loop policies. This is a pretty specific use case, and they'll have to be
updated anyway in order to implement `set_running_loop`. asyncio.set_event_loop
might be affected too, although it could be kept or deprecated.
Do you think it's worth the trouble?
----------
nosy: +vxgmichel
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
