[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

Yury Selivanov added the comment: > I have a feeling that we need a low-level API section that describes > *supported* API that is intended to task extenders only (guys who want to > provide an alternative task factory for example). I'm not sure how exposing all private method

[issue47167] Allow overriding future-task compliance check in asyncio

Yury Selivanov added the comment: Sorry, I don't like the committed change and I think it should be reverted. Futures and Tasks have a documented `get_loop()` method which simply should be called by Task machinery, without the need to expose (and document) private me

[issue45997] asyncio.Semaphore waiters deque doesn't work

Yury Selivanov added the comment: Andrew, the same problem exists in asyncio.Queue which is also critical. Here's how I fixed it in edgedb code base: https://github.com/edgedb/edgedb/blob/08e41341024828df22a01cd690b11fcff00bca5e/edb/server/compiler_pool/queue.py#L5

[issue46994] Accept explicit contextvars.Context in asyncio create_task() API

Yury Selivanov added the comment: Yeah, +1 to add a parameter. Fwiw it was on my idea list when i was working on the pep -- ___ Python tracker <https://bugs.python.org/issue46

[issue46829] Confusing CancelError message if multiple cancellations are scheduled

Yury Selivanov added the comment: IOW I think that supporting custom messages is a needless complication of our API. Given how complex task trees can become with TaskGroups collecting those messages and presenting them all to the user isn't trivial, showing just first/last defeat

[issue46829] Confusing CancelError message if multiple cancellations are scheduled

Yury Selivanov added the comment: Andrew asked me for my opinion on the matter -- I think we should get rid of the message. Exception messages for "signals" can be easily lost if an exception was re-raised. If the reason of why something is being cancelled is important (in my exp

[issue46844] Context-based TaskGroup for legacy libraries

Yury Selivanov added the comment: > I believe that this approach would allow more control over tasks implicitly > spawned by 3rd-party libraries that cannot control. Please elaborate. I'm not sure what are the benefits of this. -- ___

[issue46771] Add some form of cancel scopes

Yury Selivanov added the comment: > * `async with` vs `with`: if Andrew thinks `async with` is easier to teach > and less error-prone, It has to be 'async with' like most asyncio apis to avoid user confusion. -- ___ Python

[issue46771] Add some form of cancel scopes

Yury Selivanov added the comment: Couple thoughts: I'm +1 for adding TaskGroup.cancel() method. I'd be -1 on abusing `Task.cancel()` to signal something with a nonce. Whatever problem we are trying to solve here, it should be solvable without resorting to hacks like this. It

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

Yury Selivanov added the comment: > There's one thing that gather() does that TaskGroup doesn't: it gives us the > return values from the tasks. That's easy to do with task groups too: async with TaskGroup() as g: r1 = g.create_task(coro1()) r2

[issue20342] Endianness not detected correctly due to AC_RUN_IFELSE macros

Yury V. Zaytsev added the comment: Well, the machine that I had the problem on does no longer exist and I'm not sure whether this is a generic POWER issue. The problem was that I had to cross-compile Python on one generation of POWER machines for another POWER chip using its own sp

[issue46347] memory leak in PyEval_EvalCodeEx

Yury Selivanov added the comment: New changeset be578e0c063dad1dbb273f86d5bc77e4e6f14583 by Yury Selivanov in branch 'main': bpo-46347: Yet another fix in the erorr path of PyEval_EvalCodeEx (#30554) https://github.com/python/cpython/commit/be578e0c063dad1dbb273f86d5bc77

[issue46347] memory leak in PyEval_EvalCodeEx

Yury Selivanov added the comment: New changeset 6f9ca53a6ac343a5663cc5c52546acf9a63b605a by Yury Selivanov in branch '3.10': bpo-46347: Fix PyEval_EvalCodeEx to correctly cleanup in error paths (#30553) https://github.com/python/cpython/commit/6f9ca53a6ac343a5663cc5c52546ac

[issue46347] memory leak in PyEval_EvalCodeEx

Change by Yury Selivanov : -- pull_requests: +28755 pull_request: https://github.com/python/cpython/pull/30554 ___ Python tracker <https://bugs.python.org/issue46

[issue46347] memory leak in PyEval_EvalCodeEx

Change by Yury Selivanov : -- pull_requests: +28754 pull_request: https://github.com/python/cpython/pull/30553 ___ Python tracker <https://bugs.python.org/issue46

[issue46347] memory leak in PyEval_EvalCodeEx

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

[issue46347] memory leak in PyEval_EvalCodeEx

Yury Selivanov added the comment: New changeset 20b5791ce9b47195ce51cfd5acb223b1ca59cdf0 by Yury Selivanov in branch 'main': bpo-46347: Fix PyEval_EvalCodeEx to correctly cleanup in error paths (#30551) https://github.com/python/cpython/commit/20b5791ce9b47195ce51cfd5acb223

[issue46347] memory leak in PyEval_EvalCodeEx

Yury Selivanov added the comment: > The function will still leak "kwnames" and "default" if creating the "func" > object fails. Yeah, here's another PR to address that: https://github.com/python/cpython/pull/30551 -- _

[issue46347] memory leak in PyEval_EvalCodeEx

Change by Yury Selivanov : -- pull_requests: +28752 pull_request: https://github.com/python/cpython/pull/30551 ___ Python tracker <https://bugs.python.org/issue46

[issue46347] memory leak in PyEval_EvalCodeEx

Yury Selivanov added the comment: New changeset 607d8a838f29ad3c4c4e85b39f338dade5f9cafe by Yury Selivanov in branch 'main': bpo-46347: Fix memory leak in PyEval_EvalCodeEx. (#30546) https://github.com/python/cpython/commit/607d8a838f29ad3c4c4e85b39f338d

[issue46347] memory leak in PyEval_EvalCodeEx

Change by Yury Selivanov : -- keywords: +patch pull_requests: +28746 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30546 ___ Python tracker <https://bugs.python.org/issu

[issue46347] memory leak in PyEval_EvalCodeEx

Yury Selivanov added the comment: This is the questionable place in the code: https://github.com/python/cpython/blob/dce642f24418c58e67fa31a686575c980c31dd37/Python/ceval.c#L6131-L6166 See that `kwargs` is allocated but never freed or used

[issue46347] memory leak in PyEval_EvalCodeEx

Yury Selivanov added the comment: (this is the context of our current investigation btw: https://github.com/MagicStack/asyncpg/issues/874#issuecomment-1009383262) -- ___ Python tracker <https://bugs.python.org/issue46

[issue46347] memory leak in PyEval_EvalCodeEx

New submission from Yury Selivanov : I'm investigating a memory leak in 3.10, and while looking at the offending commit I stumbled upon this: in ceval.c:PyEval_EvalCodeEx, there's this allocation: PyObject **kwargs = PyMem_Malloc(sizeof(PyObject *)*kwcount); The problem is

[issue45123] PyAiter_Check & PyObject_GetAiter issues

Change by Yury Selivanov : -- keywords: +patch pull_requests: +26618 pull_request: https://github.com/python/cpython/pull/28194 ___ Python tracker <https://bugs.python.org/issue45

[issue45123] PyAiter_Check & PyObject_GetAiter issues

New submission from Yury Selivanov : Per discussion on python-dev (also see the linked email), PyAiter_Check should only check for `__anext__` existence (and not for `__aiter__`) to be consistent with `Py_IterCheck`. While there, I'd like to rename PyAiter_Check to PyAIter_Chec

[issue45088] Coroutines & async generators disagree on the iteration protocol semantics

Change by Yury Selivanov : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue45088> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45088] Coroutines & async generators disagree on the iteration protocol semantics

New submission from Yury Selivanov : See this script: https://gist.github.com/1st1/eccc32991dc2798f3fa0b4050ae2461d Somehow an identity async function alters the behavior of manual iteration though the wrapped nested generator. This is a very subtle bug and I'm not even sure if this

[issue22239] asyncio: nested event loop

Yury Selivanov added the comment: > nest-asyncio library (https://github.com/erdewit/nest_asyncio) Seeing that the community actively wants to have support for nested loops I'm slowly changing my opinion on this. Guido, maybe we should allow nested asyncio loops disabled by

[issue44604] [Enhancement] Asyncio task decorator to provide interface to define async DAGs (similar to dask's delayed interface)

Yury Selivanov added the comment: Yeah, I'm also not convinced this has to be part of asyncio, especially since we'll likely have task groups in 3.11. -- ___ Python tracker <https://bugs.python.o

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

Yury Selivanov added the comment: > MultiLoopChildWatcher must ensures that the event loop is awaken when it > receives a signal by using signal.setwakeup(). This is done by > _UnixSelectorEventLoop.add_signal_handler(). Maybe MultiLoopChildWatcher > could reuse this function,

[issue37146] opcode cache for LOAD_GLOBAL emits false alarm in memory leak hunting

Yury Selivanov added the comment: > Giving the ability to control the cache size, at least at Python startup, is > one option. I'd really prefer not to allow users to control cache sizes. There's basically no point in that; the only practically useful thing is to enab

[issue42990] Improve the C code for calling Python code: _PyEval_EvalCode()

Yury Selivanov added the comment: > So you think that even a dedicated "LEN" opcode would not be any faster? > (This is getting in Paul Sokolovsky territory -- IIRC he has a variant of > Python that doesn't allow overriding builtins.) Yeah, a dedicated LEN opcode co

[issue42990] Improve the C code for calling Python code: _PyEval_EvalCode()

Yury Selivanov added the comment: > I tried to implement such optimization in my old > https://faster-cpython.readthedocs.io/fat_python.html project. I implemented > guards to de-optimize the code if a builtin is overriden. FWIW the globals opcode cache handles all of this now. T

[issue42927] Inline cache for slots

Yury Selivanov added the comment: > Some microbenchmarks: Can you add a new one `read_slots`? -- ___ Python tracker <https://bugs.python.org/issu

[issue42927] Inline cache for slots

Yury Selivanov added the comment: > So it seems that everything is in the noise range except the "float" > benchmark that is 1.11x faster Yeah, this is why. https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_float.py#L12 This is a great result

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

Yury Selivanov added the comment: > Do we have good intuition or data about which operations need speeding up > most? Everybody always assumes it's BINARY_ADD, but much Python code isn't > actually numeric, and binary operations aren't all that common. IMO, we sho

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

Yury Selivanov added the comment: > The gist seems to be to have extra opcodes that only work for certain > situations (e.g. INT_BINARY_ADD). In a hot function we can rewrite opcodes > with their specialized counterpart. The new opcode contains a guard that > rewrites itself

[issue41891] asyncio.wait_for does not wait for task/future to be completed in all cases

Yury Selivanov added the comment: New changeset 82dbfd5a04863d8b6363527e6a34a90c9aa5691b by Miss Islington (bot) in branch '3.9': bpo-41891: ensure asyncio.wait_for waits for task completion (GH-22461) (#23840) https://github.com/python/cpython/commit/82dbfd5a04863d8b6363527e6a34a9

[issue42600] Cancelling tasks waiting for asyncio.Conditions crashes w/ RuntimeError: Lock is not acquired.

Yury Selivanov added the comment: This has been actually first fixed in #41891 but somehow wasn't yet merged. Yurii, thanks so much for working on this and making a PR, there was just another PR to fix the same issue that was there first, so I had to merge that one. -- resol

[issue41891] asyncio.wait_for does not wait for task/future to be completed in all cases

Change by Yury Selivanov : -- nosy: -miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41891] asyncio.wait_for does not wait for task/future to be completed in all cases

Yury Selivanov added the comment: Thanks for the PR, Richard! -- nosy: -miss-islington ___ Python tracker <https://bugs.python.org/issue41891> ___ ___ Pytho

[issue41891] asyncio.wait_for does not wait for task/future to be completed in all cases

Yury Selivanov added the comment: New changeset 17ef4319a34f5a2f95e7823dfb5f5b8cff11882d by Richard Kojedzinszky in branch 'master': bpo-41891: ensure asyncio.wait_for waits for task completion (#22461) https://github.com/python/cpython/commit/17ef4319a34f5a2f95e7823dfb5f5b

[issue42600] Cancelling tasks waiting for asyncio.Conditions crashes w/ RuntimeError: Lock is not acquired.

Yury Selivanov added the comment: Hey Hynek! :) Can you submit a PR? -- ___ Python tracker <https://bugs.python.org/issue42600> ___ ___ Python-bugs-list mailin

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

Yury Selivanov added the comment: > I will try to do some prototyping around that to see how much can we gain in > that route. In any case, adding LOAD_METHOD support for all kinds of calls > should be an improvement by itself even without caching, no? Exactly. As one arg

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

Yury Selivanov added the comment: > I think I am closing the PR as it seems that the gains are not good enough > (and there is quite a lot of noise by comparing the benchmarks together). IMO you need to implement LOAD_METHOD support for all kinds of calls, including the ones that use

[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 tracke

[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 tracke

[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 neve

[issue42085] Add dedicated slot for sending values

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

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

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

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

[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 n

[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 <https://bugs.python.org/issue42392> ___ ___ Pytho

[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 <https://bugs.python.org/issue42

[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

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

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/is

[issue42085] Add dedicated slot for sending values

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/cpyt

[issue42085] Add dedicated slot for sending values

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

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/is

[issue24165] Free list for single-digits ints

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

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

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

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

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, becau

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

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, becau

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

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

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

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

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/cfb0f57ff876ab3d04ff144f19eda5

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

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

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

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

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/037245c5ac46c3436f617a1f5d9659

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

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 sor

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

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

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: ope

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

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/2b05361bf7cbbd76035206fd9befe8

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

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

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

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

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

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 also work

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

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

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

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

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

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

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

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' no

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

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 per

[issue41733] ContextVar get value is unexpected

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 then

[issue41687] sendfile implementation is not compatible with Solaris

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 -

[issue41687] sendfile implementation is not compatible with Solaris

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

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/40e2444c364eede59f193979df5a02

[issue41696] asyncio.run interacts surprisingly with debug mode

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/a2680058ee1f43cab282e9f4c2b35f

[issue41696] asyncio.run interacts surprisingly with debug mode

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/1f5f12737755f246fee83a54c60077

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

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/8d68e59f11267ded765d4af6d71a49

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

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/a986b061a3cd4661eb9f857e293629

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

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/49571c0b0e57e20d85727c738d9a0f

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

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/be435ae2b064dc64f04475bec63286

[issue41696] asyncio.run interacts surprisingly with debug mode

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/0770ad948cb6d9f7f6c4002efd83e2

[issue41696] asyncio.run interacts surprisingly with debug mode

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

  1   2   3   4   5   6   7   8   9   10   >