[issue34014] loop.run_in_executor should propagate current contextvars

Viktor Kovtun added the comment: Hey, as I see there is no new API yet. Can we take a look again on 3) ? I'll be happy to update PR 9688 -- ___ Python tracker <https://bugs.python.org/is

[issue34014] loop.run_in_executor should propagate current contextvars

Viktor Kovtun added the comment: I've created new pull request https://github.com/python/cpython/pull/9688 with the implementation of proposed changes -- ___ Python tracker <https://bugs.python.org/is

[issue34014] loop.run_in_executor should propagate current contextvars

Change by Viktor Kovtun : -- pull_requests: +9074 ___ Python tracker <https://bugs.python.org/issue34014> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34014] loop.run_in_executor should propagate current contextvars

Viktor Kovtun added the comment: `ProcessPoolExecutor as executor is not so popular in real world` - as executor for asyncio -- ___ Python tracker <https://bugs.python.org/issue34

[issue34014] loop.run_in_executor should propagate current contextvars

Viktor Kovtun added the comment: What about to check instance of executor and depending on that propagate contextvars or not? As well to raise RuntimeError for ProcessPoolExecutor with provided context? I assume, that ProcessPoolExecutor as executor is not so popular in real world, but I

[issue34014] loop.run_in_executor should propagate current contextvars

Change by Viktor Kovtun : -- keywords: +patch pull_requests: +7645 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34014> ___ ___ Py

[issue34014] loop.run_in_executor should propagate current contextvars

New submission from Viktor Kovtun : PEP 567 supports copying context into another threads, but for asyncio users each call `run_in_executor` requires explicit context propagation For end users expected behavior that context is copied automatically -- components: asyncio messages

[issue31556] asyncio.wait_for can cancel futures faster with timeout==0

Viktor Kovtun added the comment: Actually provided example without patch will print 1, which is not expected -- ___ Python tracker <https://bugs.python.org/issue31

[issue31556] asyncio.wait_for can cancel futures faster with timeout==0

Viktor Kovtun added the comment: asyncio.wait_for is coroutine itself, to start executing code, no matter with this PR or not it needs to be awaited/yield from import asyncio @asyncio.coroutine def foo(): print(1) loop = asyncio.get_event_loop() fut = asyncio.wait_for(foo(), 0) print

[issue31556] asyncio.wait_for can cancel futures faster with timeout==0

Viktor Kovtun added the comment: If coroutine function has some blocking calls before first await/yield from statement maybe makes sense do no let them be executed, if timeout equals 0 -- ___ Python tracker <https://bugs.python.org/issue31

[issue31556] asyncio.wait_for can cancel futures faster with timeout==0

Changes by Viktor Kovtun : -- keywords: +patch pull_requests: +3687 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31556> ___ ___ Py

[issue31556] asyncio.wait_for can cancel futures faster with timeout==0

New submission from Viktor Kovtun: There is no need to create extra future and use loop.call_later to cancel base future from asyncio.wait_for when timeout==0. If loop is heavy loaded it can be cancelled simnifically later then 0 seconds later. -- components: asyncio messages: 302770