We have a situation where we're using zeroconf.Zeroconf in a server that is not using asyncio so it internally calls _start_thread() to set things up for blocking operation. However, when we tried to run this same code in a jupyter notebook for testing it detects the asyncio event loop that jupyter is running to support top-level await in cells and configures itself for async operation on the current event loop. This makes it impossible to test the code in jupyter.
Would it be possible to add a way to explicitly control whether zeroconf.Zeroconf uses asyncio or threads? For example, a new constructor arg like use_asyncio: bool | None = None. If not given, the behavior would be the same as it is today, detecting whether an asyncio event loop is running and using that to configure the class. But if an explicit boolean value is provided the class would be configured accordingly to give the user control in cases like jupyter described above where we want to ignore an existing asyncio event loop.
We have a situation where we're using
zeroconf.Zeroconfin a server that is not using asyncio so it internally calls_start_thread()to set things up for blocking operation. However, when we tried to run this same code in a jupyter notebook for testing it detects the asyncio event loop that jupyter is running to support top-levelawaitin cells and configures itself for async operation on the current event loop. This makes it impossible to test the code in jupyter.Would it be possible to add a way to explicitly control whether
zeroconf.Zeroconfuses asyncio or threads? For example, a new constructor arg likeuse_asyncio: bool | None = None. If not given, the behavior would be the same as it is today, detecting whether an asyncio event loop is running and using that to configure the class. But if an explicit boolean value is provided the class would be configured accordingly to give the user control in cases like jupyter described above where we want to ignore an existing asyncio event loop.