[issue42838] Wait for cleanup coroutines before event loop is closed.

Change by xloem <0xl...@gmail.com>: -- resolution: wont fix -> out of date ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue42838] Wait for cleanup coroutines before event loop is closed.

Change by xloem <0xl...@gmail.com>: -- resolution: out of date -> wont fix ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue42838] Wait for cleanup coroutines before event loop is closed.

xloem <0xl...@gmail.com> added the comment: hey, I don't have the capacity to stay on this, but thanks for the attention, time, and clear response. there are of course other situations such as returning a resource to library code or manual loop management, but I don't have the use case

[issue42838] Wait for cleanup coroutines before event loop is closed.

Andrew Svetlov added the comment: asyncio.run() present since Python 3.7 After the main coroutine finish, it cancels all background tasks and waits for their termination. Background tasks can use old good `try/finally` for resources cleanup. An additional API is not required IMHO.

[issue42838] Wait for cleanup coroutines before event loop is closed.

xloem <0xl...@gmail.com> added the comment: I'm sorry, is this closure an error? Could you explain more how to use asyncio.run() to clean up resources when an unhandled exception is thrown? Is this new with a recent python improvement? -- status: closed -> open

[issue42838] Wait for cleanup coroutines before event loop is closed.

Andrew Svetlov added the comment: asyncio.run() does the task -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___

[issue46341] duplicate paragraphs - asyncio Coroutines and Tasks file

Change by Serhiy Storchaka : -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Fix incorrect use of directives in asyncio documentation ___ Python tracker

[issue46341] duplicate paragraphs - asyncio Coroutines and Tasks file

Change by Kumar Aditya : -- versions: +Python 3.11 -Python 3.10 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue46341] duplicate paragraphs - asyncio Coroutines and Tasks file

New submission from Kumar Aditya : This has been fixed in GH-31388. This can be closed now. -- nosy: +AlexWaygood, kumaraditya303 ___ Python tracker ___

[issue46622] Add an async variant of lru_cache for coroutines.

Raymond Hettinger added the comment: [Andrew Svetlov] > A third-party library should either copy all these > implementation details or import a private function from stdlib OrderedDict provides just about everything needed to roll lru cache variants. It simply isn't true this can only be

[issue46622] Add an async variant of lru_cache for coroutines.

Change by Joongi Kim : -- nosy: +achimnol ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46622] Add an async variant of lru_cache for coroutines.

Serhiy Storchaka added the comment: async_lru_cache() and async_cached_property() can be written using that decorator. The implementation of async_lru_cache() is complicated because the interface of lru_cache() is complicated. But it is simpler than using _lru_cache_wrapper(). def

[issue46622] Add an async variant of lru_cache for coroutines.

Serhiy Storchaka added the comment: I think that it would be simpler to add a decorator which wraps the result of an asynchronous function into an object which can be awaited more than once: def reawaitable(func): @wraps(func) def wrapper(*args, **kwargs): return

[issue46622] Add an async variant of lru_cache for coroutines.

Tzu-ping Chung added the comment: Another thing to point out is that existing third-party solutions (both alru_cache and cached_property) only work for asyncio, and the stdlib version (as implemented now) will be an improvement. And if the position is that the improvements should only be

[issue46622] Add an async variant of lru_cache for coroutines.

Andrew Svetlov added the comment: Thanks, Raymond. I agree that caching of iterators and generators is out of the issue scope. Also, I agree that a separate async cache decorator should be added. I prefer the `async_lru_cache` (and maybe `async_cache` for the API symmetry). We have

[issue46622] Add an async variant of lru_cache for coroutines.

Change by Raymond Hettinger : -- title: Add a async variant of lru_cache for coroutines. -> Add an async variant of lru_cache for coroutines. ___ Python tracker <https://bugs.python.org/issu

[issue46622] Add a async variant of lru_cache for coroutines.

already get people who try to cache time(), random() or other impure functions. They cache methods and cannot understand why references is held for the instance. Assuredly, coroutines and futures will encounter even more misunderstandings. Also, automatic reiterability is can of worms and would

[issue44834] contextvars.Context.run w/ coroutines gives inconsistent behavior

Change by Sebastián Ramírez : -- nosy: +tiangolo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46609] Generator-based coroutines in Python 3.10, 3.9 docs

Change by Terry J. Reedy : -- nosy: -miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed title: Generator-based coroutines in Python 3.10 docs -> Generator-based coroutines in Python 3.

[issue46609] Generator-based coroutines in Python 3.10 docs

Terry J. Reedy added the comment: New changeset 459e26f0987a12a19238baba422e13a8f7fcfca3 by Miss Islington (bot) in branch '3.9': [3.9] bpo-46609: Update asyncio-task coroutine doc (GH-31132) https://github.com/python/cpython/commit/459e26f0987a12a19238baba422e13a8f7fcfca3 --

[issue46609] Generator-based coroutines in Python 3.10 docs

Terry J. Reedy added the comment: New changeset 5603db43ba7ba5568b7516d0e28730a2bc1e1f26 by Terry Jan Reedy in branch '3.10': [3.10] bpo-46609: Update asyncio-task coroutine doc (GH-31132) https://github.com/python/cpython/commit/5603db43ba7ba5568b7516d0e28730a2bc1e1f26 --

[issue46609] Generator-based coroutines in Python 3.10 docs

Change by miss-islington : -- nosy: +miss-islington nosy_count: 5.0 -> 6.0 pull_requests: +29312 pull_request: https://github.com/python/cpython/pull/31133 ___ Python tracker

[issue46609] Generator-based coroutines in Python 3.10 docs

Change by Terry J. Reedy : -- keywords: +patch pull_requests: +29311 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31132 ___ Python tracker

[issue46609] Generator-based coroutines in Python 3.10 docs

Terry J. Reedy added the comment: Looking at the doc answered the question. Further down the 3.10 version, '3.10' was revised to '3.11', and indeed, the decorator and the entire section are gone. There was no change in 3.9 doc, but should be. I will submit a PR for 3.10 and try to

[issue46609] Generator-based coroutines in Python 3.10 docs

Terry J. Reedy added the comment: Yuri or Andrew: either of you know the fix for "Support for generator-based coroutines is deprecated and is scheduled for removal in Python 3.10."? -- nosy: +asvetlov, terry.reedy, yselivanov ___ Pyth

[issue46609] Generator-based coroutines in Python 3.10 docs

New submission from Sebastian Rittau : Currently, the Python 3.10.2 documentation at https://docs.python.org/3/library/asyncio-task.html?highlight=coroutine#asyncio.coroutine says: "Note: Support for generator-based coroutines is deprecated and is scheduled for removal in Python

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

Andrew Svetlov added the comment: You are welcome! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

Change by Andrew Svetlov : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

bluecarrot added the comment: You are absolutely correct. Thank you very much! -- ___ Python tracker ___ ___ Python-bugs-list

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

Andrew Svetlov added the comment: Your version works but can be simplified. Just use await writer.drain() writer.write(data) without grabbing the drainer early. The purpose of the .drain() method is to write pausing if the write buffer side is greater than the high watermark.

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

bluecarrot added the comment: Hi Andrew, thank you for your answer. I am experimenting with coroutines, as I am pretty new to them. My idea was to let the writer drain while other packets where read, and thus I am waiting for the writer_drain right before starting writer.write again. Isn't

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

Andrew Svetlov added the comment: Your code has at least one concurrency problem. Let's look back at forward_stream() function: async def forward_stream(reader: StreamReader, writer: StreamWriter, event: asyncio.Event, source: str): writer_drain = writer.drain() # <--- awaitable is

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

bluecarrot added the comment: Seems that, should I add an "await asyncio.sleep(1)" in asyncTearDown, so getting class TestConnections(IsolatedAsyncioTestCase): async def asyncSetUp(self) -> None: self.proxy = asyncio.create_task(EnergyAgentProxy(self.proxy_port,

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

New submission from bluecarrot : I am unittesting a tcp proxy module using coroutines. This is the coroutine I am using to do the forwarding, allowing the writer stream to drain while the rest of the coroutines are proceeding: async def forward_stream(reader: StreamReader, writer

[issue46341] duplicate paragraphs - asyncio Coroutines and Tasks file

Change by Alex Waygood : -- nosy: +asvetlov, yselivanov stage: -> needs patch type: -> behavior ___ Python tracker ___ ___

[issue46341] duplicate paragraphs - asyncio Coroutines and Tasks file

Change by David : -- assignee: docs@python components: Documentation nosy: davem, docs@python priority: normal pull_requests: 28731 severity: normal status: open title: duplicate paragraphs - asyncio Coroutines and Tasks file versions: Python 3.10

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

Change by Yury Selivanov : -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

if this is a bug or not. Opening the issue so that I don't forget about this and debug sometime later. -- components: Interpreter Core messages: 400951 nosy: lukasz.langa, pablogsal, yselivanov priority: normal severity: normal stage: needs patch status: open title: Coroutines & async genera

[issue44834] contextvars.Context.run w/ coroutines gives inconsistent behavior

Change by Adrian Garcia Badaracco : -- nosy: +yselivanov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44834] contextvars.Context.run w/ coroutines gives inconsistent behavior

New submission from Adrian Garcia Badaracco : I recently tried to use `contextvars.Context.run` w/ coroutines, expecting the same behavior as with regular functions, but it seems that `contextvars.Context.run` does not work w/ coroutines. I'm sorry if this is something obvious to do with how

[issue44407] A "Coroutines and Tasks" code example needs "asyncio.run(main())"

Andrei Kulakov added the comment: I think it's clear that the modification of previous example is limited to `main()` because `say_after()` is also omitted. This is very common in Python code examples, - it seems to me this change is not needed. -- nosy: +andrei.avk

[issue44407] A "Coroutines and Tasks" code example needs "asyncio.run(main())"

New submission from Atsushi Sakai : This is very small documentation improvement proposal. In the "Coroutines and Tasks" doc, the code example after "Let’s modify the above example and run two say_after coroutines concurrently:" is missing "asyncio.run(main())"

[issue42838] Wait for cleanup coroutines before event loop is closed.

New submission from xloem <0xl...@gmail.com>: To handle destruction of resources especially during exceptions, it would be nice if there were some way to provide coroutines/tasks that run at the termination or closure of an event loop. There are a lot of api options here. Maybe a

Re: [Python-ideas] asyncio: return from multiple coroutines

ncio.wait with `FIRST_COMPLETED`; > however, the problem is that it seems to evict the not-completed coroutines, > so the messenger that arrives second does not send the message. To check it, > I have run that script without the random sleep. just msgr1 waits 1s and > msgr2 waits 2s, so msgr1

Re: [Python-ideas] asyncio: return from multiple coroutines

details on the functionality of > asyncio.wait(), see > https://docs.python.org/3/library/asyncio-task.html#asyncio.wait. > > I understand that I can create two coroutines that call the same > function, but it would be much cleaner (because of implementation issues) > if I can s

[issue40844] Alternate ways of running coroutines

Change by Yury Selivanov : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue40844] Alternate ways of running coroutines

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

[issue40844] Alternate ways of running coroutines

New submission from Matthew Francis <4576fran...@gmail.com>: Currently, using await inside a coroutine will block inside the coroutine. This behavior would usually be fine, but for some usecases a way to nonblockingly run coroutines without creating a Task could be useful, because

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

Batuhan Taskaya added the comment: > This can be closed, but for completeness, the test you ran didn't verify that > the bug was fixed. This is because the hard coded compile flags I gave in my > example seem to have changed in Python 3.9 (is this documented?). Yes, this is documented on

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

Jonathan Crall added the comment: This can be closed, but for completeness, the test you ran didn't verify that the bug was fixed. This is because the hard coded compile flags I gave in my example seem to have changed in Python 3.9 (is this documented?). In python3.8 the compile flags I

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

STINNER Victor added the comment: > I first noticed this when testing xdoctest on Python 3.9, and then again when > using IPython. What is your Python 3.9 exact version number? I cannot reproduce your issue with Python 3.9.0a6: vstinner@apu$ ./python -c "print(eval(compile('[i for i in

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

STINNER Victor added the comment: I close the issue: it's already fixed in 3.9.0a6. If it's not the case, feel free to reopen the issue ;-) -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

Jonathan Crall added the comment: Ah, sorry. I neglected all the important information. I tested this using: Python 3.9.0a5 (default, Apr 23 2020, 14:11:34) [GCC 8.3.0] Specifically, I ran in a docker container: DOCKER_IMAGE=circleci/python:3.9-rc docker pull $DOCKER_IMAGE docker run

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

I can't find any notes in the CHANGELOG that seem to correspond to it. -- components: Interpreter Core messages: 367651 nosy: Jonathan Crall priority: normal severity: normal status: open title: Python 3.9 eval on list comprehension sometimes returns coroutines vers

[issue39034] Documentation: Coroutines

Andrew Svetlov added the comment: I suggest thinking that gather() implicitly creates tasks for running coroutines. The documentation is technically correct, enumeration of all potentially endless list of things that calls `create_task()` for wrapping passed coroutine is not very helpful

[issue39034] Documentation: Coroutines

Change by Karthikeyan Singaravelan : -- components: +asyncio nosy: +asvetlov, yselivanov ___ Python tracker ___ ___

[issue39034] Documentation: Coroutines

it be added to docs? -- assignee: docs@python components: Documentation messages: 358320 nosy: agarus, docs@python priority: normal severity: normal status: open title: Documentation: Coroutines type: enhancement versions: Python 3.7 ___ Python tracker <

Awaiting coroutines inside the debugger (PDB)

Hi everyone, this question is sort of in response to this issue https://github.com/gotcha/ipdb/issues/174. I've noticed that there was recently added support for an asyncio repl (run via `python -m asyncio`), which allows the use of `await` directly on coroutine objects in the REPL. But this

[issue30773] async generator receives wrong value when shared between coroutines

Change by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue30773] async generator receives wrong value when shared between coroutines

Yury Selivanov added the comment: New changeset 2f87a7dc5a1ad7f37787f0adee242c931643f878 by Yury Selivanov (Miss Islington (bot)) in branch '3.8': bpo-30773: Fix ag_running; prohibit running athrow/asend/aclose in parallel (GH-7468) (#16486)

[issue30773] async generator receives wrong value when shared between coroutines

Yury Selivanov added the comment: New changeset fc4a044a3c54ce21e9ed150f7d769fb479d34c49 by Yury Selivanov in branch 'master': bpo-30773: Fix ag_running; prohibit running athrow/asend/aclose in parallel (#7468)

[issue30773] async generator receives wrong value when shared between coroutines

Change by miss-islington : -- pull_requests: +16072 pull_request: https://github.com/python/cpython/pull/16486 ___ Python tracker ___

[issue33918] Hooking into pause/resume of iterators/coroutines

Change by Andrew Svetlov : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue33918] Hooking into pause/resume of iterators/coroutines

Andrew Svetlov added the comment: decimal was changed from threading.local to contextvar usage. The module is "safe" not only for asyncio but for threading, trio etc. unittest.mock doesn't use explicit context all for patching. It changes global interpreter-wide objects instead. So,

[issue35040] functools.lru_cache does not work with coroutines

Andrew Svetlov added the comment: A coroutine detection is a relatively slow check. I don't think we need to do it in `functools.lru_cache`. There is a specialized asyncio compatible version: https://github.com/aio-libs/async_lru Please use it. --

[issue35040] functools.lru_cache does not work with coroutines

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35040] functools.lru_cache does not work with coroutines

New submission from Liran Nuna : lru_cache is a very useful method but it does not work well with coroutines since they can only be executed once. Take for example, the attached code (test-case.py) - It will throw a RuntimeError because you cannot reuse an already awaited coroutine

Re: asyncio await different coroutines on the same socket?

eping a record of Tasks that are waiting and calling "set_result" > > on those Tasks when finished. Also Task isn’t even documented to have the > > set_result method (though "future" is) > > Because Tasks are used to wrap coroutines, and the result of the

Re: asyncio await different coroutines on the same socket?

n documented to have the > set_result method (though "future" is) Because Tasks are used to wrap coroutines, and the result of the Task should be determined by the coroutine, not externally. Instead of tracking tasks (that's what the event loop is for) I would suggest tracking

Re: asyncio await different coroutines on the same socket?

Task isn’t even documented to have the > set_result method (though "future" is) I don't really get what you want to achieve. Do you want to signal other coroutines that one of the others finished ? From what I understand, you want to have several coroutines reading on the same s

asyncio await different coroutines on the same socket?

Using asyncio I am looking for a simple way to await multiple events where notification comes over the same socket (or other serial stream) in arbitrary order. For example, suppose I am communicating with a remote device that can run different commands simultaneously and I don't know which

[issue30773] async generator receives wrong value when shared between coroutines

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29471] AST: add an attribute to FunctionDef to distinguish functions from generators and coroutines

STINNER Victor added the comment: > I'm not sure we need this feature TBH. Ok, I close the issue. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker

[issue34701] Asyncio documentation for recursive coroutines is lacking

Azaria Zornberg added the comment: Ah, thanks for the clarification! I first encountered this when having some issues with converting large objects to json. json.dumps happens synchronously, and when executed on an object that was dozens of MB in size, it held up everything for a fair bit

[issue34701] Asyncio documentation for recursive coroutines is lacking

Yury Selivanov added the comment: The issue here is not the recursion, but rather about the fact that coroutines should actually await on IO or other activity in order for the event loop to run them cooperatively. E.g. async def foo(): await foo() doesn't really do anything

[issue34701] Asyncio documentation for recursive coroutines is lacking

Change by Azaria Zornberg : -- keywords: +patch pull_requests: +8762 stage: -> patch review ___ Python tracker ___ ___

[issue34701] Asyncio documentation for recursive coroutines is lacking

New submission from Azaria Zornberg : When an asynchronous coroutine in asyncio awaits or yields from itself, any call to the function is executed somewhat synchronously. Once the recursive coroutine begins, if it never awaits any other coroutines besides itself, nothing else

[issue33918] Hooking into pause/resume of iterators/coroutines

Liran Nuna added the comment: > That's still doable with contextvars. You just need a custom mock-like object > (or library) that stores its settings/state in a context variable. contextvars only work with asyncio, what about the iterator case? In addition, you can't possibly expect authors

[issue33918] Hooking into pause/resume of iterators/coroutines

Yury Selivanov added the comment: > Imagine the context manager is mock.patch used in testing and you want to run > two tests in "parallel", each with a different mocked method. mock.patch > isn't aware of `await` so patching will be incorrect. That's still doable with contextvars. You just

[issue33918] Hooking into pause/resume of iterators/coroutines

Liran Nuna added the comment: > You should try to use the contextvars module that was specifically created to > handle local context state (for tasks & coroutines). Yury, from my original report: > I'm aware that this particular problem could be solved with the new context

[issue33918] Hooking into pause/resume of iterators/coroutines

Yury Selivanov added the comment: You should try to use the contextvars module that was specifically created to handle local context state (for tasks & coroutines). -- ___ Python tracker <https://bugs.python.org/iss

[issue33918] Hooking into pause/resume of iterators/coroutines

Liran Nuna added the comment: I would like to stress this issue happens with iterators as well, and this isn't a unique issue to asyncio only. I would like to propose four new magic methods for context managers to solve this: __pause__, __resume__, __apause__ and __aresume__ which will be

[issue33918] Hooking into pause/resume of iterators/coroutines

Change by Ned Deily : -- components: +asyncio -Interpreter Core nosy: +asvetlov, yselivanov versions: -Python 3.4, Python 3.5 ___ Python tracker ___

[issue33918] Hooking into pause/resume of iterators/coroutines

ther). Is there a way to hook into a pause/resume handling of coroutines so this kind of thing could be done correctly? I'm aware that this particular problem could be solved with the new context variables introduced with python3.7, however it is just a simplification of our actual issue. Iterato

[issue30773] async generator receives wrong value when shared between coroutines

Change by Yury Selivanov : -- keywords: +patch pull_requests: +7091 stage: -> patch review ___ Python tracker ___ ___

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

Yury Selivanov added the comment: Yes, thanks Ned -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

Ned Deily added the comment: Can we close this now? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

Yury Selivanov added the comment: New changeset e151f83deab9819fb8d9dfc59f9baa4a7273226c by Yury Selivanov in branch '3.6': bpo-33672: Fix Task.__repr__ crash with Cython's bogus coroutines (GH-7180) https://github.com/python/cpython/commit/e151f83deab9819fb8d9dfc59f9baa4a7273226c

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

Yury Selivanov added the comment: Ned, this one would be nice to have in 3.7.0. -- nosy: +ned.deily priority: normal -> release blocker ___ Python tracker ___

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

Change by Yury Selivanov : -- pull_requests: +6815 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

Yury Selivanov added the comment: New changeset 075c662086859f864aa1179f57367aa470ee6335 by Yury Selivanov (Miss Islington (bot)) in branch '3.7': bpo-33672: Fix Task.__repr__ crash with Cython's bogus coroutines (GH-7161) (GH-7173) https://github.com/python/cpython/commit

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

Ned Deily added the comment: bug fix, go for it. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

Change by miss-islington : -- pull_requests: +6808 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

New submission from Yury Selivanov : New changeset 989b9e0e6d7dd2fa911f9bfd4744e7f3a82d6006 by Yury Selivanov in branch 'master': bpo-33672: Fix Task.__repr__ crash with Cython's bogus coroutines (GH-7161) https://github.com/python/cpython/commit/989b9e0e6d7dd2fa911f9bfd4744e7f3a82d6006

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

Change by Yury Selivanov : -- keywords: +patch pull_requests: +6796 stage: -> patch review ___ Python tracker ___

[issue33672] Fix Task.__repr__ crash when trying to format Cython's bogus coroutines

Change by Yury Selivanov <yseliva...@gmail.com>: -- components: asyncio nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Fix Task.__repr__ crash when trying to format Cython's bogus coroutines type: behavior versions: Python 3.6, Python 3.7, Pyth

[issue30773] async generator receives wrong value when shared between coroutines

Yury Selivanov added the comment: Thanks, I'll look into adding ag_running properly. -- ___ Python tracker ___

[issue30773] async generator receives wrong value when shared between coroutines

Nathaniel Smith added the comment: My thoughts: https://bugs.python.org/issue32526#msg309783 -- ___ Python tracker ___

[issue30773] async generator receives wrong value when shared between coroutines

Change by Yury Selivanov : -- assignee: -> yselivanov components: +Interpreter Core -asyncio priority: normal -> high versions: +Python 3.8 ___ Python tracker

  1   2   3   4   >