[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/issue34014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 nosy: asvetlov, hellysmile, yselivanov priority: normal severity: normal status: open title: asyncio.wait_for can cancel futures faster with timeout==0 versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue31556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue31556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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('it is not raised yet')
try:
loop.run_until_complete(fut)
except asyncio.TimeoutError:
print('raised here')
will print
it is not raised yet
raised here
--
___
Python tracker
<https://bugs.python.org/issue31556>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue31556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: 320814 nosy: asvetlov, hellysmile, yselivanov priority: normal severity: normal status: open title: loop.run_in_executor should propagate current contextvars versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 can not provide any stats. Different behavior is defiantly at least weird, but do not support natively what is technically expected also strange. https://docs.python.org/3.7/library/contextvars.html#asyncio-support `Context variables are natively supported in asyncio` is hard for end users. Each use case of contextvars + run_in_executor will produce copy-paste boilerplate As for me it is very similar to the `asyncio.get_event_loop()` history -- ___ Python tracker <https://bugs.python.org/issue34014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue34014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue34014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
