[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Andrew Svetlov added the comment: New changeset e4fe303b8cca525e97d44e80c7e53bdab9dd9187 by Yurii Karabas in branch 'master': bpo-42392: Remove loop parameter from asyncio.tasks and asyncio.subprocess (GH-23521)

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Terry J. Reedy added the comment: I would attach simple PRs based on the discussion here to this issue. If a particular change needs additional and particular discussion, I would open a separate PR, announce it here, and list it in the Dependencies box. Then this generic issue, 'Remove

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Change by Yurii Karabas <1998uri...@gmail.com>: -- pull_requests: +22405 pull_request: https://github.com/python/cpython/pull/23521 ___ Python tracker ___

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Andrew Svetlov added the comment: A few functions in `tasks.py` a left and documentation should be updated. -- ___ Python tracker ___

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Andrew Svetlov added the comment: New changeset f533cb80cbbb7acdf9ce1978cfba095ce5eeedaa by Yurii Karabas in branch 'master': bpo-42392: Remove loop parameter from asyncio.streams (GH-23517) https://github.com/python/cpython/commit/f533cb80cbbb7acdf9ce1978cfba095ce5eeedaa --

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Change by Yurii Karabas <1998uri...@gmail.com>: -- pull_requests: +22402 pull_request: https://github.com/python/cpython/pull/23517 ___ Python tracker ___

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Andrew Svetlov added the comment: > Should I create a separate issue for every PR or they all can be done in the > scope of this PR (we can update issue title to match what was done)? Up to you, I don't think it really matters. -- ___ Python

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Kyle Stanley added the comment: New changeset b9127dd6eedd693cfd716a648864e2e00186 by Yurii Karabas in branch 'master': bpo-42392: Improve removal of *loop* parameter in asyncio primitives (GH-23499) https://github.com/python/cpython/commit/b9127dd6eedd693cfd716a648864e2e00186

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Yurii Karabas <1998uri...@gmail.com> added the comment: Should I create a separate issue for every PR or they all can be done in the scope of this PR (we can update issue title to match what was done)? -- ___ Python tracker

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Kyle Stanley added the comment: > Is there anyone who is assigned to removing the deprecated `loop` parameter > from `asyncio` codebase? > If not I can take this task, I believe I have enough free time and curiosity > to do that :) You can certainly feel free to work on that and it would

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Yurii Karabas <1998uri...@gmail.com> added the comment: Is there anyone who is assigned to removing the deprecated `loop` parameter from `asyncio` codebase? If not I can take this task, I believe I have enough free time and curiosity to do that :) --

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Change by Yurii Karabas <1998uri...@gmail.com>: -- pull_requests: +22389 pull_request: https://github.com/python/cpython/pull/23499 ___ Python tracker ___

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Yury Selivanov added the comment: Sorry, there are a few things in the committed patch that should be fixed. See the PR for my comments. -- resolution: fixed -> stage: resolved -> patch review status: closed -> open ___ Python tracker

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Change by Andrew Svetlov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement ___ Python tracker ___

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Andrew Svetlov added the comment: New changeset 0ec34cab9dd4a7bcddafaeeb445fae0f26afcdd1 by Yurii Karabas in branch 'master': bpo-42392: Remove loop parameter form asyncio locks and Queue (#23420) https://github.com/python/cpython/commit/0ec34cab9dd4a7bcddafaeeb445fae0f26afcdd1 --

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Change by Yurii Karabas <1998uri...@gmail.com>: -- keywords: +patch nosy: +uriyyo nosy_count: 3.0 -> 4.0 pull_requests: +22313 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23420 ___ Python tracker

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Andrew Svetlov added the comment: Perfect! We have a consensus now and waiting for a champion who propose a Pull Request. -- ___ Python tracker ___

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Yury Selivanov added the comment: > The safe code can look like: > > global_lock = threading.Lock() like GIL SGTM. We can use this strategy for all synchronization primitives and for objects like asyncio.Queue. -- ___ Python tracker

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Andrew Svetlov added the comment: Perhaps Kyle is right, I had a misunderstanding with `get_running_loop()` vs `_get_running_loop()`. The last version seems good except for the rare chance of race condition. The safe code can look like: global_lock = threading.Lock() like GIL def

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Kyle Stanley added the comment: Regarding the example _get_loop(): ``` def _get_loop(self): loop = asyncio.get_running_loop() if self._loop is None: self._loop = loop if loop is not self._loop: raise if not loop.is_running():

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Yury Selivanov added the comment: > Despite the fact that asyncio.get_running_loop() never returns None but > raises RuntimeError (and maybe other tiny cleanups), It never raises when called from inside a coroutine. And I propose to do that. So it will never fail. --

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Andrew Svetlov added the comment: Despite the fact that asyncio.get_running_loop() never returns None but raises RuntimeError (and maybe other tiny cleanups), I can live with the proposal. It doesn't make a system worse at least and backward compatible. We can return to the idea of raising

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Yury Selivanov added the comment: Yeah, I follow the reasoning. My use case: class Something: def __init__(self): self._lock = asyncio.Lock() async def do_something(): async with self._lock: ... And `Something` won't be created in a

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Andrew Svetlov added the comment: My initial thought was protecting the Lock (and other primitives) creation when a loop is not running. Yuri insists that Lock can be created without a loop. Technically it is possible, sure. But the lock is tightly coupled with a loop instance. In other

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Yury Selivanov added the comment: > That's good to know and I think more convenient to work with, so +1 from me. > I guess my remaining question though is whether it's okay to `await > lock.acquire()` on a single lock instance from multiple different running > event loops (presumably each

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Kyle Stanley added the comment: > Oh my. FWIW I think that we need to implement this differently. I don't > think it matters where, say, an asyncio.Lock was instantiated. It can be > created anywhere. So IMO its __init__ shouldn't try to capture the current > loop -- there's no need for

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Yury Selivanov added the comment: Oh my. FWIW I think that we need to implement this differently. I don't think it matters where, say, an asyncio.Lock was instantiated. It can be created anywhere. So IMO its __init__ shouldn't try to capture the current loop -- there's no need for that.

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Kyle Stanley added the comment: Sure, I would be interested in helping with this. Although if a newer contributor takes it up before I'm able to, I wouldn't be opposed to that either (my main priority at the moment is helping with PEP 594 since it's a concrete goal of my internship w/ the

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Andrew Svetlov added the comment: This was on my to-do list but I very much appreciate if somebody champions this issue. I should finish sslproto PR first. -- ___ Python tracker

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Yury Selivanov added the comment: Kyle, lmk if you want to work on this. -- nosy: +aeros ___ Python tracker ___ ___

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

Yury Selivanov added the comment: (or alternatively they can cache the running `loop`, but the first loop lookup should be performed with `asyncio.get_running_loop()`) -- ___ Python tracker

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

New submission from Yury Selivanov : asyncio.Lock and other primitives should no longer accept the `loop` parameter. They should also stop storing the current loop in the `self._loop` attribute. Instead, they should use `get_running_loop()` whenever they need to access the loop. --