Yury Selivanov added the comment:
Alex, do you want to submit a PR?
--
___
Python tracker
<https://bugs.python.org/issue41317>
___
___
Python-bugs-list mailin
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/0dd98c2d00a75efbec19c2ed942923
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 mention
Yury Selivanov added the comment:
I'm OK with adding this, but the close method should be `aclose()`
--
___
Python tracker
<https://bugs.python.org/is
Change by Yury Selivanov :
--
nosy: +asvetlov, njs
___
Python tracker
<https://bugs.python.org/issue41197>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 track
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/c
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/a2118a14627256197bddcf4fcecad4
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/cpyt
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/c
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/ea5a6363c3f8cc90b7c0cc573922b1
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
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
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
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
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
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
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
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
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
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<https://bugs.python
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
-
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
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
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
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
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
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
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-
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
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
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
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
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
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
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
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
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
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
Change by Yury Selivanov :
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue41756>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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
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
Change by Yury Selivanov :
--
Removed message: https://bugs.python.org/msg379330
___
Python tracker
<https://bugs.python.org/issue42115>
___
___
Python-bug
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
Change by Yury Selivanov :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue24165>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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
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
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
Yury Selivanov added the comment:
Kyle, lmk if you want to work on this.
--
nosy: +aeros
___
Python tracker
<https://bugs.python.org/issue42392>
___
___
Pytho
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
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
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
Yury Selivanov added the comment:
> Is anything left to do?
I think we can close this now.
--
___
Python tracker
<https://bugs.python.org/issue42085>
___
_
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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
New submission from Yury Selivanov :
WeakSet has a bug in its '__len__' method, where it performs iteration though
'self.data' without ensuring _IterationGuard.
This leads to some hard to catch errors with the following traceback:
builtins.RuntimeError: Set changed s
Yury Selivanov added the comment:
Yes, I couldn't reproduce it either. However it frequently occurs on our
buildbot, so tomorrow I'll give you an update if this patch resolves the issue
or not.
In any way, your patch fixes the current implementation at least from the
p
Yury Selivanov added the comment:
As expected, it seems that the patch fixes the issue.
--
___
Python tracker
<http://bugs.python.org/issue14159>
___
___
Pytho
New submission from Yury Selivanov :
I think that the documentation should put more emphasis on the `return`
statement in a `finally` block.
Example:
def test():
try:
1/0
finally:
return 10
>>> test()
10
I think we need to add a warning, or a
Yury Selivanov added the comment:
Well, I guess the best place to put it would be
http://docs.python.org/py3k/reference/compound_stmts.html#finally
I've attached the patch, please take a look. If it's possible to make it more
clear, feel free to rephrase it. But please include t
New submission from Yury Selivanov :
__code__ and __closure__ are designed to work together. There is no point in
allowing to completely substitute the __code__ object, but protecting the
__closure__.
--
components: Interpreter Core
files: writable_closure.patch
keywords: patch
Changes by Yury Selivanov :
Removed file: http://bugs.python.org/file24943/writable_closure.patch
___
Python tracker
<http://bugs.python.org/issue14369>
___
___
Python-bug
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file24946/writable_closure.patch
___
Python tracker
<http://bugs.python.org/issue14369>
___
___
Python-bug
Yury Selivanov added the comment:
Updated patch as per Andrew's code review. Thank you.
--
Added file: http://bugs.python.org/file24947/writable_closure_02.patch
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
> Please update the doc also. I think changing from 'Read-only' to 'Writable'
> in Doc/reference/datamodel.rst is enough.
Updated in writable_closure_03.patch. Thanks.
--
Added file: http://bugs.python.org/file24962
Yury Selivanov added the comment:
Updated patch per Benjamin's review. See writable_closure_04.patch.
--
Added file: http://bugs.python.org/file24975/writable_closure_04.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Yury Selivanov :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue14369>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +Yury.Selivanov
___
Python tracker
<http://bugs.python.org/issue14397>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
I vote for adding just one function to the 'time' module: monotonic(),
which should exist only if the host OS support it.
And I don't see the point of having 'steady()' at all.
--
Yury Selivanov added the comment:
> A monotonic clock is not suitable for measuring durations, as it may still
> jump forward. A steady clock will not.
Well, Victor's implementation of 'steady()' is just a tiny wrapper, which uses
'monotonic()' or 'ti
Changes by Yury Selivanov :
--
nosy: +Yury.Selivanov
___
Python tracker
<http://bugs.python.org/issue13903>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
New changeset 565b4f1ac7304d1e690c404ca8316f383ba60862 by Yury Selivanov
(Matthias Bussonnier) in branch 'master':
bpo-34616: Add PyCF_ALLOW_TOP_LEVEL_AWAIT to allow top-level await (GH-13148)
https://github.com/python/cpyt
Change by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34616>
___
___
Yury Selivanov added the comment:
I've no problem with this. We can add a 'get_coro()' Task method (this is in
line with asyncio usually having the "getter" api as opposed to properties).
--
___
Python tracker
<https:
Change by Yury Selivanov :
--
pull_requests: +13385
___
Python tracker
<https://bugs.python.org/issue34616>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> Would it be possible to document this change in What's New in Python 3.8?
Yes, Elvis and I will take care of that later.
--
___
Python tracker
<https://bugs.python.org
Yury Selivanov added the comment:
> And I'm guessing you will collect what's in NEWS.d ? Otherwise I'm happy to
> contribute some text. let me know the best way.
Would be great if you could make a PR to add an entry to whatsnew/3.8.rst
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +13442
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32528>
___
___
Py
New submission from Yury Selivanov :
Currently asyncio exposes the underlying transport socket directly, providing a
way to modify (in a potentially disruptive way) the underlying transport
connection.
--
messages: 343332
nosy: yselivanov
priority: normal
severity: normal
status
Change by Yury Selivanov :
--
components: +asyncio
nosy: +asvetlov
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue37027>
___
___
Pytho
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +13444
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue37027>
___
___
Py
New submission from Yury Selivanov :
Having an asyncio enabled repr where a top-level "await" possible would be a
huge productivity boost. Using asyncio.run() in a REPL is hard, and besides it
spawns a new event loop on every call.
The big idea: we want users to be able
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +13446
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue37028>
___
___
Py
Yury Selivanov added the comment:
New changeset 16cefb0bc7b05c08caf08525398ff178c35dece4 by Yury Selivanov in
branch 'master':
bpo-37028: asyncio REPL; activated via 'python -m asyncio'. (GH-13472)
https://github.com/python/cpython/commit/16cefb0bc7b05c08caf0
Yury Selivanov added the comment:
The REPL has been merged to 3.8. It's not perfect though -- a ^C might break
the asyncio event loop, sometimes ^C stops working altogether. We'll
investigate all these issues in follow up PRs.
--
stage: patch review -> resolved
Yury Selivanov added the comment:
New changeset 431b540bf79f0982559b1b0e420b1b085f667bb7 by Yury Selivanov in
branch 'master':
bpo-32528: Make asyncio.CancelledError a BaseException. (GH-13528)
https://github.com/python/cpython/commit/431b540bf79f0982559b1b0e420b1b
Yury Selivanov added the comment:
Done. 🤞 we don't regret this.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
Yury Selivanov added the comment:
New changeset ff6b2e66b19a26b4c2ab57e62e1ab9f3d94dd76a by Yury Selivanov
(Xtreak) in branch 'master':
bpo-37047: Refactor AsyncMock setup logic for autospeccing (GH-13574)
https://github.com/python/cpython/commit/ff6b2e66b19a26b4c2ab57e62e1ab9
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Yury Selivanov added the comment:
> I suggest "Python asyncio REPL 3.8.0a4+ (...)". I prefer to keep "Python"
> somewhere.
Sure.
> Is "exiting asyncio REPL..." message really helpful? If exit can block, would
> it possible to only display a me
201 - 300 of 3129 matches
Mail list logo
