MOTOR-979 Use asyncio.get_event_loop so that DeprecationWarnings are correctly issued

[graingert]

…issued

It looks like a workaround I wrote in Tornado was incorrectly incorporated into AsyncioMotorClient here https://github.com/mongodb/motor/pull/155/files#r851429040

if a user has opted into DeprecationWarnings as errors asyncio.get_event_loop_policy().get_event_loop() incorrectly suppresses the deprecation warning:

Python 3.10.4 (main, Apr  8 2022, 17:35:13) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import motor.motor_asyncio
>>> client = motor.motor_asyncio.AsyncIOMotorClient()
>>> client.test.pages.drop()  # this should raise a DeprecationWarning because it was called without a running loop
<Future pending cb=[_chain_future.<locals>._call_check_cancel() at /usr/lib/python3.10/asyncio/futures.py:384]>
>>> 

[ShaneHarvey]

client.test.pages.drop() # this should raise a DeprecationWarning because it was called without a running loop

I think there's a misunderstanding here. We don't want this line to raise a DeprecationWarning or fail with an error because a loop wasn't created. We intentionally decided that we what this code to continue working like it does in Python <3.9 where motor will implicitly create and start a loop on the current thread. With that in mind, we can't merge this PR. Is there an alternative way you'd suggest accomplishing our goal?

[graingert]

This will only raise a DeprecationWarning if the caller has opted into this behavior

[ShaneHarvey]

We don't want this line to raise a DeprecationWarning even if the user opts into warnings.

[blink1073]

I think @graingert's point is that we're masking an issue that will cause breakage in Python 3.12 (assuming they stick to their schedule of aliasing get_event_loop() to get_running_loop()).

[ShaneHarvey]

In this case I think that CPython is incorrectly not raising DeprecationWarning from asyncio.get_event_loop_policy().get_event_loop(). We should open a python bug for that.

Perhaps we should revisit this and just follow asyncio's lead. We'd need to re-evaluate the problem as a whole though. For example, if we create a client before there's a loop (or a running loop) should we auto create a new loop? Or should we pin to the current loop when the client is first used?

[graingert]

For example, if we create a client before there's a loop (or a running loop)

This works correctly already, as AsyncIOMotorClient now mostly follows the asyncio.mixins._LoopBoundMixin pattern:

Python 3.10.4 (main, Apr  8 2022, 17:35:13) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import motor.motor_asyncio
>>> client = motor.motor_asyncio.AsyncIOMotorClient()  # before #155 this raised a DeprecationWarning and bound the wrong loop
>>> client.test.pages.drop()  # this should raise a DeprecationWarning because it was called without a running loop
<Future pending cb=[_chain_future.<locals>._call_check_cancel() at /usr/lib/python3.10/asyncio/futures.py:384]>
>>> 

[ShaneHarvey]

Okay I believe I'm on the same page now. I opened https://jira.mongodb.org/browse/MOTOR-979 to track.

[ShaneHarvey]

LGTM!

[blink1073]

I opened https://jira.mongodb.org/browse/MOTOR-980 to track the docs failure. Thanks @graingert!