[docs] [issue36373] Deprecate explicit loop parameter in all public asyncio APIs

[Yury Selivanov]

Yury Selivanov <yselivanov at gmail.com> added the comment:

(copying my GitHub message on this topic from https://github.com/python/cpython/pull/15889#issuecomment-530030002)


I thought we were going to be more subtle about this.

We have two scenarios:

Somebody creates an instance of asyncio.Lock outside of a coroutine, also manually creating the loop, etc. In this case the user has to pass the lock argument.

Somebody creates an instance of asyncio.Lock in a coroutine (that is, wheh asyncio.get_running_loop() returns a loop). In this case passing the loop argument is an error.

The (1) approach is how people were used to writing asyncio programs before asyncio.run() (that was the only way actually).

The (2) approach is how we want people to write asyncio programs.

There's a subtle difference between things like asyncio.gather() and asyncio.Lock. Passing loop to the former is just nonsensical. Passing loop to the latter can be a valid thing, it's the (1).

If we remove the loop parameter entirely from classes like asyncio.Lock we're making (1) impossible. I'm not sure that is what we are ready to do now.

@asvetlov thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36373>
_______________________________________