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

2020-11-24 Thread Yury Selivanov
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 tracke

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

2020-11-19 Thread Yury Selivanov
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 tracke

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

2020-11-18 Thread Yury Selivanov
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 neve

[issue42085] Add dedicated slot for sending values

2020-11-18 Thread Yury Selivanov
Change by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42085] Add dedicated slot for sending values

2020-11-18 Thread Yury Selivanov
Yury Selivanov added the comment: > Is anything left to do? I think we can close this now. -- ___ Python tracker <https://bugs.python.org/issue42085> ___ _

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

2020-11-18 Thread Yury Selivanov
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

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

2020-11-17 Thread Yury Selivanov
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 (pre

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

2020-11-17 Thread Yury Selivanov
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

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

2020-11-17 Thread Yury Selivanov
Yury Selivanov added the comment: Kyle, lmk if you want to work on this. -- nosy: +aeros ___ Python tracker <https://bugs.python.org/issue42392> ___ ___ Pytho

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

2020-11-17 Thread Yury Selivanov
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 <https://bugs.python.org/issue42

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

2020-11-17 Thread Yury Selivanov
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

[issue42140] asyncio.wait function creates futures set two times

2020-11-10 Thread Yury Selivanov
Yury Selivanov added the comment: Thanks for the change and for the discussion to everybody involved. The PR makes sense and I've already merged it. -- ___ Python tracker <https://bugs.python.org/issue42

[issue42085] Add dedicated slot for sending values

2020-11-10 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 1e996c3a3b51e9c6f1f4cea8a6dbcf3bcb865060 by Vladimir Matveev in branch 'master': bpo-42085: Introduce dedicated entry in PyAsyncMethods for sending values (#22780) https://github.com/python/cpython/commit

[issue42085] Add dedicated slot for sending values

2020-11-10 Thread Yury Selivanov
Yury Selivanov added the comment: Vladimir, please do a follow up PR documenting Py_TPFLAGS_HAVE_AM_SEND. -- ___ Python tracker <https://bugs.python.org/issue42

[issue24165] Free list for single-digits ints

2020-10-22 Thread Yury Selivanov
Yury Selivanov added the comment: Inada-san, how do you interpret the results? Looks like it's performance-neutral. -- ___ Python tracker <https://bugs.python.org/issue24

[issue24165] Free list for single-digits ints

2020-10-22 Thread Yury Selivanov
Change by Yury Selivanov : -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue24165> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42117] asyncio calls from sync/async, better docs or api support

2020-10-22 Thread Yury Selivanov
Yury Selivanov added the comment: I'm not sure what you're actually proposing, and only have a vague understanding of what you're complaining about. This is perhaps related to https://bugs.python.org/issue33523? If so then maybe leave a comment

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

2020-10-22 Thread Yury Selivanov
Change by Yury Selivanov : -- Removed message: https://bugs.python.org/msg379330 ___ Python tracker <https://bugs.python.org/issue42115> ___ ___ Python-bug

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

2020-10-22 Thread Yury Selivanov
Yury Selivanov added the comment: > This idea can be implemented without opcode cache. I will try it. I'd actually encourage trying to use the opcode cache because this way the optimization will be more generic. E.g. `decimal + decimal` would also be specialized via the cache, because yo

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

2020-10-22 Thread Yury Selivanov
Yury Selivanov added the comment: > This idea can be implemented without opcode cache. I will try it. I'd actually encourage trying to use the opcode cache because this way the optimization will be more generic. E.g. `decimal + decimal` would also be specialized via the cache, because yo

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

2020-10-21 Thread Yury Selivanov
Yury Selivanov added the comment: > Imagine that we have a secondary copy of the bytecode in the cache inside the > code object and we mutate that instead. The key difference with the current > cache infrastructure is that we don't accumulate all the optimizations on the >

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

2020-10-21 Thread Yury Selivanov
Yury Selivanov added the comment: Few thoughts in no particular order: - I'd suggest implementing the cache for 2-3 more opcodes on top of the existing infrastructure to get more experience and then refactoring it to make it more generic. - Generalizing LOAD_METHOD to work for methods

[issue42113] Replace _asyncio.TaskWakeupMethWrapper with PyCFunction

2020-10-21 Thread Yury Selivanov
Change by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41756] Do not always use exceptions to return result from coroutine

2020-10-13 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset cfb0f57ff876ab3d04ff144f19eda58844981643 by Vladimir Matveev in branch 'master': bpo-41756: Export PyGen_Send and wrap it in if-defs (#22677) https://github.com/python/cpython/commit/cfb0f57ff876ab3d04ff144f19eda58844981643

[issue41756] Do not always use exceptions to return result from coroutine

2020-10-12 Thread Yury Selivanov
Yury Selivanov added the comment: > Also, in Include/abstract.h it should only be available for limited C API >= > 3.10: Vladimir, could you please submit a PR? > We now should discuss the behavior of PySend_Iter() if value is NULL. It is > not documented, the current behavi

[issue41756] Do not always use exceptions to return result from coroutine

2020-10-12 Thread Yury Selivanov
Change by Yury Selivanov : -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue41756> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue41756] Do not always use exceptions to return result from coroutine

2020-10-12 Thread Yury Selivanov
Yury Selivanov added the comment: With the latest PR now merged this issue can be closed. Please reopen if there are any other action items left. -- stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue41756] Do not always use exceptions to return result from coroutine

2020-10-09 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 037245c5ac46c3436f617a1f5d965929754be239 by Vladimir Matveev in branch 'master': bpo-41756: Add PyIter_Send function (#22443) https://github.com/python/cpython/commit/037245c5ac46c3436f617a1f5d965929754be239

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-21 Thread Yury Selivanov
Yury Selivanov added the comment: > If you disagree with me, please say why, don't just merge the PR. Apologies, Mark. I didn't intend to merge something bypassing your opinion; just missed your comment between reviewing multiple PRs in a few unrelated repos. I'm sorry. On the act

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-20 Thread Yury Selivanov
Yury Selivanov added the comment: Vladimir, could you please submit a PR to update 3.10/whatsnew? Need to mention both the new C API and the new perf boost in relevant sections. -- ___ Python tracker <https://bugs.python.org/issue41

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-18 Thread Yury Selivanov
Yury Selivanov added the comment: Thanks, Vladimir! Also huge thanks to Mark, Serhiy, and Stefan. If there are any nits to fix let's do that in follow up PRs. -- resolution: -> fixed stage: patch review -> resolved status: open -&g

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-18 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 2b05361bf7cbbd76035206fd9befe87f37489f1e by Vladimir Matveev in branch 'master': bpo-41756: Introduce PyGen_Send C API (GH-22196) https://github.com/python/cpython/commit/2b05361bf7cbbd76035206fd9befe87f37489f1e

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-18 Thread Yury Selivanov
Yury Selivanov added the comment: > Sounds like a good middleground to start: add ``PySendResult `` and > `PySendResult PyGen_Send(PyGenObject*, PyObject* PyObject**)` specific to > generators and coroutines. Yes, it seems that everybody agreed on that. I can give the PR anoth

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-18 Thread Yury Selivanov
Yury Selivanov added the comment: > I would also have preferred a more type specific function, but yeah, as long > as the types for which the function would normally be used are special cased > early enough in the implementation, it makes no big difference. Maybe add two

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-17 Thread Yury Selivanov
Yury Selivanov added the comment: > Does it sound correct? It does, but given the amount of back and forth on this, I'd wait for Serhiy and Stefan to confirm if they're OK. IMO the `PyIter_Send` name is OK (given how generic the implementation will be) and returning an enum, while a

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-17 Thread Yury Selivanov
Yury Selivanov added the comment: > I guess `PyIter_Send` would imply that this function should work for all > inputs (like in https://bugs.python.org/msg377007) which also sounds > reasonable. I like `PyIter_Send` (and why I initially proposed it myself) because it will

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-16 Thread Yury Selivanov
Yury Selivanov added the comment: > I think it should be specific to generators and coroutines. Calling > `PyObject_CallMethodIdOneArg(coro, _send, arg);` and interpreting > exceptions to emulate the low level API seems a bit too much. To add to my point: typically higher-leve

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-16 Thread Yury Selivanov
Yury Selivanov added the comment: > Since coroutines inherit the generator protocol more or less, I think > "PyGen_Send()" is a more suitable name, better than "PyCoro_Send()". OK, +1. PyGen_Send it is. > Also should it be specific to generators/coroutines and

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-16 Thread Yury Selivanov
Yury Selivanov added the comment: > As for returned value, I propose to return -1 in case of error, 1 for yielded > value and 0 for returned value (i.e. define PYGEN_RETURN = 0, PYGEN_YIELD = 1 > and PYGEN_ERROR = -1, but without exposing public names). Sure, t

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-16 Thread Yury Selivanov
Yury Selivanov added the comment: Mark, Stefan, I don't want this to be stale so I propose to move with my suggestions: 1. We make the new API public. Mark, if you have objections to that - please elaborate with some details. IMO, the corresponding Python API is long public and there's

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-11 Thread Yury Selivanov
Yury Selivanov added the comment: @Mark > Mark Shannon wrote: I don't think [the C-API function] should be public, as a > possible further improvement is to stop passing exceptions through a side > channel, but in result. Maybe we don't want to do that, but lets' not add to >

[issue41756] Do not always use exceptions to return result from coroutine

2020-09-10 Thread Yury Selivanov
Yury Selivanov added the comment: Big +1 from me. This is something I always wanted to do myself (since the time of PEP 492 & 525 implementations) and I think this is a necessary change. It's great that this isn't just a C API UX improvement but also yields a big perf improve

[issue41733] ContextVar get value is unexpected

2020-09-08 Thread Yury Selivanov
Yury Selivanov added the comment: > my expected result is all objects should be different, because the code runs > in different context. Contexts "branch", so if you store something in the context before asyncio.run it will store it in the current thread state. And

[issue41687] sendfile implementation is not compatible with Solaris

2020-09-05 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 8c0be6fd9101746235b63ddfb84106d1e9ca286b by Jakub Kulík in branch 'master': bpo-41687: Fix sendfile implementation to work with Solaris (#22040) https://github.com/python/cpython/commit/8c0be6fd9101746235b63ddfb84106d1e9ca286b -- nosy

[issue41687] sendfile implementation is not compatible with Solaris

2020-09-05 Thread Yury Selivanov
Change by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior ___ Python tracker <https://bugs.python

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

2020-09-03 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 40e2444c364eede59f193979df5a02ed958f56e9 by Miss Islington (bot) in branch '3.8': bpo-39010: Improve test shutdown (GH-22066) (#22083) https://github.com/python/cpython/commit/40e2444c364eede59f193979df5a02ed958f56e9

[issue41696] asyncio.run interacts surprisingly with debug mode

2020-09-03 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset a2680058ee1f43cab282e9f4c2b35fd89464ebb6 by Miss Islington (bot) in branch '3.9': bpo-41696: Fix handling of debug mode in asyncio.run (GH-22069) (#22071) https://github.com/python/cpython/commit/a2680058ee1f43cab282e9f4c2b35fd89464ebb6

[issue41696] asyncio.run interacts surprisingly with debug mode

2020-09-03 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 1f5f12737755f246fee83a54c600779ad76934a4 by Miss Islington (bot) in branch '3.8': bpo-41696: Fix handling of debug mode in asyncio.run (GH-22069) (#22072) https://github.com/python/cpython/commit/1f5f12737755f246fee83a54c600779ad76934a4

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

2020-09-03 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 8d68e59f11267ded765d4af6d71a49784a12fad5 by Miss Islington (bot) in branch '3.9': bpo-39010: Improve test shutdown (GH-22066) (#22082) https://github.com/python/cpython/commit/8d68e59f11267ded765d4af6d71a49784a12fad5

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

2020-09-03 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset a986b061a3cd4661eb9f857e2936291f1847bd15 by Miss Islington (bot) in branch '3.8': bpo-39010: Fix errors logged on proactor loop restart (GH-22017) (#22035) https://github.com/python/cpython/commit/a986b061a3cd4661eb9f857e2936291f1847bd15

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

2020-09-03 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 49571c0b0e57e20d85727c738d9a0fe342dd2938 by Miss Islington (bot) in branch '3.9': bpo-39010: Fix errors logged on proactor loop restart (GH-22017) (#22034) https://github.com/python/cpython/commit/49571c0b0e57e20d85727c738d9a0fe342dd2938

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

2020-09-02 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset be435ae2b064dc64f04475bec632862e1dbf605f by Ben Darnell in branch 'master': bpo-39010: Improve test shutdown (#22066) https://github.com/python/cpython/commit/be435ae2b064dc64f04475bec632862e1dbf605f

[issue41696] asyncio.run interacts surprisingly with debug mode

2020-09-02 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 0770ad948cb6d9f7f6c4002efd83e27c27069808 by Shantanu in branch 'master': bpo-41696: Fix handling of debug mode in asyncio.run (#22069) https://github.com/python/cpython/commit/0770ad948cb6d9f7f6c4002efd83e27c27069808

[issue41696] asyncio.run interacts surprisingly with debug mode

2020-09-02 Thread Yury Selivanov
Yury Selivanov added the comment: Yes, this is a bug. The default for the `debug` parameter should be `None` and it should only call `loop.set_debug` if a non-None bool value was explicitly passed. Care to submit a PR? -- ___ Python tracker

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

2020-08-31 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset ea5a6363c3f8cc90b7c0cc573922b10f296073b6 by Ben Darnell in branch 'master': bpo-39010: Fix errors logged on proactor loop restart (#22017) https://github.com/python/cpython/commit/ea5a6363c3f8cc90b7c0cc573922b10f296073b6

[issue32751] wait_for(future, ...) should wait for the future (even if a timeout occurs)

2020-08-26 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 57b698886b47bb81c782c2ba80a8a72fe66c7aad by Elvis Pranskevichus in branch '3.8': [3.8] bpo-32751: Wait for task cancel in asyncio.wait_for() when timeout <= 0 (GH-21895) (#21967) https://github.com/python/cpython/com

[issue37658] In some cases asyncio.wait_for can lead to socket leak.

2020-08-26 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 6e1954cd8286e083e7f8d09516d91b6b15769a4e by Miss Islington (bot) in branch '3.8': bpo-37658: Fix asyncio.wait_for() to respect waited task status (GH-21894) (#21965) https://github.com/python/cpython/commit

[issue37658] In some cases asyncio.wait_for can lead to socket leak.

2020-08-26 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset a2118a14627256197bddcf4fcecad4c264c1e39d by Elvis Pranskevichus in branch 'master': bpo-37658: Fix asyncio.wait_for() to respect waited task status (#21894) https://github.com/python/cpython/commit/a2118a14627256197bddcf4fcecad4c264c1e39d

[issue32751] wait_for(future, ...) should wait for the future (even if a timeout occurs)

2020-08-26 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset c517fc712105c8e5930cb42baaebdbe37fc3e15f by Elvis Pranskevichus in branch 'master': bpo-32751: Wait for task cancel in asyncio.wait_for() when timeout <= 0 (#21895) https://github.com/python/cpython/com

[issue41543] contextlib.nullcontext doesn't work with async context managers

2020-08-13 Thread Yury Selivanov
Yury Selivanov added the comment: I typically don't like objects that support both `with` and `async with`, but in this case I think that's appropriate. Nathaniel, Andrew, what do you think? -- nosy: +njs ___ Python tracker <ht

[issue41197] Async magic methods in contextlib.closing

2020-08-10 Thread Yury Selivanov
Change by Yury Selivanov : -- nosy: +asvetlov, njs ___ Python tracker <https://bugs.python.org/issue41197> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41197] Async magic methods in contextlib.closing

2020-08-10 Thread Yury Selivanov
Yury Selivanov added the comment: I'm OK with adding this, but the close method should be `aclose()` -- ___ Python tracker <https://bugs.python.org/issue41

[issue41438] TimeoutError behavior changes on async.wait_for from python3.7

2020-07-29 Thread Yury Selivanov
Yury Selivanov added the comment: > In python 3.8.4 running this script will print: > asyncio.TimeoutError happened This is the expected behavior in 3.8. > This is a breaking change which I didn't see announced in the changelog. Yeah, looks like this wasn't mentioned in w

[issue41317] sock_accept() does not remove server socket reader on cancellation

2020-07-23 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 0dd98c2d00a75efbec19c2ed942923981bc06683 by Alex Grönholm in branch 'master': bpo-41317: Remove reader on cancellation in asyncio.loop.sock_accept() (#21595) https://github.com/python/cpython/commit/0dd98c2d00a75efbec19c2ed942923981bc06683

[issue41317] sock_accept() does not remove server socket reader on cancellation

2020-07-22 Thread Yury Selivanov
Yury Selivanov added the comment: Alex, do you want to submit a PR? -- ___ Python tracker <https://bugs.python.org/issue41317> ___ ___ Python-bugs-list mailin

[issue41305] Add StreamReader.readinto()

2020-07-16 Thread Yury Selivanov
Yury Selivanov added the comment: > By the way if we will eventually combine StreamReader and StreamWriter won't > this function (readinto) be useful then? Yes. But StreamReader and StreamWriter will stay for the foreseeable future for backwards compatibility pretty much frozen i

[issue41305] Add StreamReader.readinto()

2020-07-16 Thread Yury Selivanov
Yury Selivanov added the comment: > Is it simply combining stream reader and stream writer into a single object > and changing the write() function to always wait the write (thus deprecating > drain) and that's it? Pretty much. We might also rename a few APIs here and there, li

[issue41305] Add StreamReader.readinto()

2020-07-15 Thread Yury Selivanov
Yury Selivanov added the comment: > Im interested in learning about the new api. There are two problems with the current API: 1. Reader and writer are separate objects, while they should be one. 2. Writer.write is not a coroutine, although it should be one. There are other minor n

[issue41305] Add StreamReader.readinto()

2020-07-15 Thread Yury Selivanov
Yury Selivanov added the comment: We don't want to extend StreamReader with new APIs as ultimately we plan to deprecate it. A new streams API is needed, perhaps inspired by Trio. Sadly, I'm -1 on this one. -- ___ Python tracker <ht

[issue41273] asyncio: proactor read transport: use recv_into instead of recv

2020-07-14 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 568fb0ff4aa641329261cdde20795b0aa9278175 by Tony Solomonik in branch 'master': bpo-41273: asyncio's proactor read transport's better performance by using recv_into instead of recv (#21442) https://github.com/python/cpython/commit

[issue37179] asyncio loop.start_tls() provide support for TLS in TLS

2020-07-09 Thread Yury Selivanov
Yury Selivanov added the comment: > The aiohttp issue says they won't fix this until asyncio supports it. Kinda > understand that. I saw you opened an issue with aiohttp to allow this and they're open to it. I hope that will get some movement. It also would be a big test for uv

[issue41247] asyncio.set_running_loop() cache running loop holder

2020-07-09 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 0b6169e391ce6468aad711f08ffb829362293ad5 by Tony Solomonik in branch '3.8': bpo-41247: asyncio.set_running_loop() cache running loop holder (#21406) https://github.com/python/cpython/commit/0b6169e391ce6468aad711f08ffb829362293ad5

[issue41202] Allow to provide custom exception handler to asyncio.run()

2020-07-09 Thread Yury Selivanov
Yury Selivanov added the comment: > So how about maybe: That wouldn't work. You still haven't explained what's wrong with calling `loop = asyncio.get_running_loop()` inside `async def main()`. That literally solves all problems without the need of us modifying any A

[issue37179] asyncio loop.start_tls() provide support for TLS in TLS

2020-07-08 Thread Yury Selivanov
Yury Selivanov added the comment: Looks like https://github.com/python/cpython/pull/17975 was forgotten and was never committed to 3.9. So it's 3.10 now. Best bet for you is to use uvloop which should support the feature. -- ___ Python tracker

[issue41247] asyncio.set_running_loop() cache running loop holder

2020-07-08 Thread Yury Selivanov
Yury Selivanov added the comment: > n python to know if there could be a context switch to get_running_loop while > set_running_loop is running. No, it's protected by the GIL. Good catch, and merged. -- nosy: +yselivanov resolution: -> fixed stage: patch review -> res

[issue41244] Change to use str.join() instead of += when concatenating string

2020-07-08 Thread Yury Selivanov
Yury Selivanov added the comment: > Changes in bpo-41242 were rejected not because the new code is worse, but > because it is not obviously and significantly better that the existing code. > Here status quo wins for the same reasons. This rule saves us from endless > rewrit

[issue22239] asyncio: nested event loop

2020-07-07 Thread Yury Selivanov
Yury Selivanov added the comment: > The community is hurting *A LOT* right now because asyncio is intentionally > non-compatible with the traditional blocking approach that is not only still > prevalent it's one that a lot of us think is *easier* to work with. Mike, I'm su

[issue22239] asyncio: nested event loop

2020-07-07 Thread Yury Selivanov
Yury Selivanov added the comment: > Yeah, writing a trivial "event loop" to drive actually-synchronous code is > easy. Try it out: This is exactly the approach I used in edgedb-python. > I guess there's technically some overhead, but it's tiny. Correct, the overhead is

[issue22239] asyncio: nested event loop

2020-07-06 Thread Yury Selivanov
Yury Selivanov added the comment: > I think this is a really critical technique to have so that libraries that > mediate between a user-facing facade and TCP based backends no longer have to > make a hard choice about if they are to support sync vs. async (or async with > an o

[issue41202] Allow to provide custom exception handler to asyncio.run()

2020-07-06 Thread Yury Selivanov
Yury Selivanov added the comment: The idiomatic way: async def main(): loop = asyncio.get_running_loop() loop.set_exception_handler(...) # other code asyncio.run(main()) We don't want to add new arguments to asyncio.run as there would be too many

[issue22239] asyncio: nested event loop

2020-07-06 Thread Yury Selivanov
Yury Selivanov added the comment: Thanks for posting this, Mike. > Vague claims of "framework X is faster because it's async" appear, impossible > to confirm as it is unknown how much of their performance gains come from the > "async" aspect and how muc

[issue40967] asyncio.Task.all_tasks() and asyncio.Task.current_task() must be removed in 3.9

2020-06-29 Thread Yury Selivanov
Yury Selivanov added the comment: > Optimally, we want to do removals before the beta so that users can prepare > accordingly rather than deal with breakage in the final release. +1 to remove it now. Up to Lukasz to give us green or red light here,

[issue40802] AbstractEventLoop.shutdown_default_executor breaks backwards compatibility

2020-06-09 Thread Yury Selivanov
Yury Selivanov added the comment: > Since asyncio is no longer provisional, should it break backwards > compatibility with just a What's New entry? Adding new APIs to asyncio can't be classified as a backward compatibility issue. Otherwise the development of it would stall and nobody

[issue40816] Add missed AsyncContextDecorator to contextlib

2020-06-02 Thread Yury Selivanov
Yury Selivanov added the comment: This has long been implemented: https://docs.python.org/3/library/contextlib.html#contextlib.asynccontextmanager -- nosy: +yselivanov ___ Python tracker <https://bugs.python.org/issue40

[issue40844] Alternate ways of running coroutines

2020-06-02 Thread Yury Selivanov
Change by Yury Selivanov : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40844> ___ ___

[issue40844] Alternate ways of running coroutines

2020-06-02 Thread Yury Selivanov
Yury Selivanov added the comment: > I'm suggesting a method on coroutines that runs them without blocking, and > will run a callback when it's complete. And how would that method be implemented? Presumably the event loop would execute the coroutine, but that API is already there, an

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

2020-05-28 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset dc4eee9e266267498a6b783a0abccc23c06f2b87 by Fantix King in branch 'master': bpo-30064: Properly skip unstable loop.sock_connect() racing test (GH-20494) https://github.com/python/cpython/commit/dc4eee9e266267498a6b783a0abccc23c06f2b87

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

2020-05-27 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 210a137396979d747c2602eeef46c34fc4955448 by Fantix King in branch 'master': bpo-30064: Fix asyncio loop.sock_* race condition issue (#20369) https://github.com/python/cpython/commit/210a137396979d747c2602eeef46c34fc4955448

[issue40696] "await" hangs in Python3.9.0b1.

2020-05-20 Thread Yury Selivanov
Yury Selivanov added the comment: > If someone else agrees, I can create a new issue. I'd keep this one issue, but really up to you. I don't think I have time in the next few days to work on what I proposed but would be happy to brainstorm / review

[issue40696] "await" hangs in Python3.9.0b1.

2020-05-20 Thread Yury Selivanov
Yury Selivanov added the comment: Just a note, __context__ cycles can theoretically be longer than 2 nodes. I've encountered cycles like `exc.__context__.__context__.__context__ is exc` a few times in my life, typically resulting from some weird third-party libraries. The only solution

[issue40672] asyncio.wait_for: process future result produced during cancelation

2020-05-18 Thread Yury Selivanov
Yury Selivanov added the comment: > 2) Add some warning about the value is thrown away (in debug mode) and > document it somewhere. The documentation update is definitely something that needs to be done in 3.9. Want to submit a PR? We can also issue a warning in asyncio debug mode

[issue31033] Add argument to .cancel() of Task and Future

2020-05-17 Thread Yury Selivanov
Yury Selivanov added the comment: Elevating to release blocker to make sure it's included. The PR is good. -- ___ Python tracker <https://bugs.python.org/issue31

[issue31033] Add argument to .cancel() of Task and Future

2020-05-17 Thread Yury Selivanov
Change by Yury Selivanov : -- priority: normal -> release blocker ___ Python tracker <https://bugs.python.org/issue31033> ___ ___ Python-bugs-list mai

[issue40607] asyncio.wait_for should reraise future exception even if timeout expires

2020-05-15 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset 382a5635bd10c237c3e23e346b21cde27e48d7fa by romasku in branch 'master': bpo-40607: Reraise exception during task cancelation in asyncio.wait_for() (GH-20054) https://github.com/python/cpython/commit/382a5635bd10c237c3e23e346b21cde27e48d7fa

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

2020-05-13 Thread Yury Selivanov
Yury Selivanov added the comment: New changeset de92769d473d1c0955d36da2fc71462621326f00 by jack1142 in branch 'master': bpo-34790: add version of removal of explicit passing of coros to `asyncio.wait`'s documentation (#20008) https://github.com/python/cpython/commit

[issue40607] asyncio.wait_for should reraise future exception even if timeout expires

2020-05-13 Thread Yury Selivanov
Yury Selivanov added the comment: > I think that in case inner task cancelation fails with some error, > asyncio.wait_for should reraise it instead of silently losing it. +1. -- ___ Python tracker <https://bugs.python.org/i

[issue40257] Improve the use of __doc__ in pydoc

2020-05-13 Thread Yury Selivanov
Change by Yury Selivanov : -- nosy: -yselivanov ___ Python tracker <https://bugs.python.org/issue40257> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40526] documentation bad on asyncio

2020-05-06 Thread Yury Selivanov
Yury Selivanov added the comment: > If so, the main purpose of that example is just to demonstrate basic > async/await syntax, and show asyncio.run() for a trivial case to clearly show > how it's used at a fundamental level; it's intentional that the more involved &

[issue40454] DEBUG kw to asyncio.run overrides DEBUG mode set elsewhere

2020-05-04 Thread Yury Selivanov
Yury Selivanov added the comment: Good catch. The function should be fixed to: _marker = object() def run(coro, *, debug=_marker): if debug is not _marker: loop.set_debug(debug) -- ___ Python tracker <https://bugs.python.

[issue39562] Asynchronous comprehensions don't work in asyncio REPL

2020-05-01 Thread Yury Selivanov
Change by Yury Selivanov : -- nosy: -yselivanov ___ Python tracker <https://bugs.python.org/issue39562> ___ ___ Python-bugs-list mailing list Unsubscribe:

  1   2   3   4   5   6   7   8   9   10   >