You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I appreciate that this is unlikely to be a priority but I thought it worth recording for future reference. There is scope for a subtle bug to occur in user code where a contributed module is used:
importuasyncioasasyncioimportsome_modulebar=some_module.Bar() # Constructor calls get_event_loop()# and renders these args inoperativeloop=asyncio.get_event_loop(runq_len=40, waitq_len=40)
I can envisage this puzzling users unfamiliar with the code of uasyncio and/or some_module. It could be avoided (with a trivial got_event_loop() function) if the class could test for instantiation.
uasyncio.core.py:
defgot_event_loop():
return_event_loopisnotNone
In some_module:
classFoo():
def__init__(self):
ifasyncio.got_event_loop():
loop=asyncio.get_event_loop()
loop.create_task(self._run())
else:
raiseOSError('Foo class requires an event loop instance')
The text was updated successfully, but these errors were encountered:
I appreciate that this is unlikely to be a priority but I thought it worth recording for future reference. There is scope for a subtle bug to occur in user code where a contributed module is used:
I can envisage this puzzling users unfamiliar with the code of
uasyncio
and/orsome_module
. It could be avoided (with a trivialgot_event_loop()
function) if the class could test for instantiation.uasyncio.core.py:
In
some_module
:The text was updated successfully, but these errors were encountered: