This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yselivanov
Recipients asvetlov, docs@python, dtrauma, eamanu, mbussonn, miss-islington, xtreak, yselivanov
Date 2019-09-10.17:04:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1568135079.33.0.850858595992.issue36373@roundup.psfhosted.org>
In-reply-to
Content
(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?
History
Date User Action Args
2019-09-10 17:05:10yselivanovunlinkissue36373 messages
2019-09-10 17:04:39yselivanovsetrecipients: + yselivanov, asvetlov, docs@python, mbussonn, eamanu, miss-islington, xtreak, dtrauma
2019-09-10 17:04:39yselivanovsetmessageid: <1568135079.33.0.850858595992.issue36373@roundup.psfhosted.org>
2019-09-10 17:04:39yselivanovlinkissue36373 messages
2019-09-10 17:04:39yselivanovcreate