Change by Yury Selivanov :
--
nosy: -yselivanov
___
Python tracker
<https://bugs.python.org/issue31939>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> On the other hand, the Future implementation is entirely not thread-safe
> (btw, the constructor optimistically claims the done callbacks are scheduled
> using call_soon_threadsafe(), but the implementation actually calls
> call_soon()).
T
Yury Selivanov added the comment:
>> I think we should update `Future._schedule_callbacks` to check if the loop
>> is in debug mode.
> Unfortunately this is not sufficient for the snippet I posted. The loop's
> thread_id is only set when the loop runs, but the ma
Yury Selivanov added the comment:
> My underlying question is why the Future has to set its loop in its
> constructor, instead of simply using get_event_loop() inside
> _schedule_callbacks(). This would always work.
So imagine a Future `fut` is completed. And we call `fut.add_done
Yury Selivanov added the comment:
> Just try the snippet :-) If you want to see it finish in a finite time, move
> the future instantiation inside the coroutine.
Yeah, I see the problem. OTOH your proposed change to lazily attach a loop to
the future isn't fully backwards comp
Yury Selivanov added the comment:
I guess you can set Resolution to "postponed", Stage to "Resolved".
--
___
Python tracker
<https://bug
Yury Selivanov added the comment:
Thank you for helping with asyncio! I'll try to get to that transport
performance issues you found sometime this week. I've a few ideas how to add
0-copy support to protocols.
--
___
Python track
Yury Selivanov added the comment:
> IMHO performance is a good motivation to enhance the asyncio API ;-) The
> tricky part is to keep the backward compatibility.
Let's stop the discussion in this ticket :)
--
___
Python trac
Yury Selivanov added the comment:
New changeset bf9d317626eebcf79bd0756b4dd43df82d5cc186 by Yury Selivanov (Tom
Floyer) in branch 'master':
bpo-31810: added missing keywords to docs. (#4140)
https://github.com/python/cpython/commit/bf9d317626eebcf79bd0756b4dd43df82d5cc186
-
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Yury Selivanov :
--
resolution: fixed ->
stage: resolved -> patch review
status: closed -> open
___
Python tracker
<https://bugs.python.or
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +4318
___
Python tracker
<https://bugs.python.org/issue28369>
___
___
Python-bugs-list mailin
Change by Yury Selivanov :
--
nosy: +asvetlov
___
Python tracker
<https://bugs.python.org/issue28369>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Guido,
The second example ("No active exception to reraise") was an actual long open
bug. It was recently fixed by Mark Shannon in [1].
I think we should be able to fix the first case (missing __context__) although
it's not critical. I&
Yury Selivanov added the comment:
New changeset ce12629c84400c52734859e43b2386deb2b6da12 by Yury Selivanov in
branch 'master':
bpo-28369: Enhance transport socket check in add_reader/writer (#4365)
https://github.com/python/cpython/commit/ce12629c84400c52734859e43b2386
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Yury Selivanov :
--
nosy: -yselivanov
___
Python tracker
<https://bugs.python.org/issue32012>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> The bugfix could be backported to Python 3.6 but I very not sure about the
> need for 3.5.
> It is a desirable fix but not secure.
The attached script looks very innocent, and it's worrisome that it's that easy
to make an asyncio SSL ser
Yury Selivanov added the comment:
New changeset 762b9571c9c8c6b036f1bf90140a1d030b3f9a01 by Yury Selivanov
(Dong-hee Na) in branch 'master':
bpo-32018: Fix inspect.signature repr to follow PEP 8 (#4408)
https://github.com/python/cpython/commit/762b9571c9c8c6b036f1bf90140a1d
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Yury Selivanov :
--
pull_requests: +4358
___
Python tracker
<https://bugs.python.org/issue32034>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> Does such a fix looks correct to you ?
No, this fix won't restore exception.args properly. I made a PR with a fix.
--
___
Python tracker
<https://bugs.python.org
New submission from Yury Selivanov :
asyncio has a few APIs that accept a Python socket object: loop.sock_recv(),
loop.sock_accept() etc.
asyncio (and event loops such as uvloop) expect that it controls the socket for
the duration of the call. However, it cannot prevent the socket object
Yury Selivanov added the comment:
> Why not instead add `loop.sock_close()`?
It wouldn't help if the program calls `socket.close()` somewhere. This can
happen easily in big code bases.
Ideally (at least I think so) we need to provide a guarantee that the socket
object can't
Change by Yury Selivanov :
--
pull_requests: +4360
___
Python tracker
<https://bugs.python.org/issue26579>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
New changeset 43605e6bfa8d49612df4a38460d063d6ba781906 by Yury Selivanov in
branch 'master':
bpo-32034: Make IncompleteReadError & LimitOverrunError pickleable #4409
https://github.com/python/cpython/commit/43605e6bfa8d49612df4a38460
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Yury Selivanov added the comment:
New changeset f35076a002b958f991d180d6f945344cc5ab3900 by Yury Selivanov (Miss
Islington (bot)) in branch '3.6':
bpo-32034: Make IncompleteReadError & LimitOverrunError pickleable GH-4409
(#4411)
https://github.com/python/
Yury Selivanov added the comment:
> It's worse than a resource leak - the same file descriptor number could be
> reused for a different file/socket, and then depending on the selector in
> use, you could see the data from a completely different connection.
I actually debug
Yury Selivanov added the comment:
> The socket.socket (Python type) has a private _io_refs counter. close() does
> nothing until _io_refs reachs zero.
I didn't know about this. Looks like I can use '_io_refs' to fix some problems
in uvloop, thanks Victor!
The only p
Yury Selivanov added the comment:
> Oh, sock._decref_socketios() must be uesd here to really close the socket if
> it was closed in the meanwhile:
For it to work correctly, socket objects should be initialized with
"self._
Change by Yury Selivanov :
--
Removed message: https://bugs.python.org/msg306374
___
Python tracker
<https://bugs.python.org/issue32038>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
> Oh, sock._decref_socketios() must be uesd here to really close the socket if
> it was closed in the meanwhile:
There's also 'sock._closed' attribute that sock.close() and sock.
_decref_socketios() interact with.. Alright, let me pla
Yury Selivanov added the comment:
> Hmm... _decref_socketios() is not really a public API. I think it would be
> nice to have an official way to deal with this, and a socket close callback
> sounds reasonable to me.
We can just make it public (after some renames) :) My first id
Yury Selivanov added the comment:
> Perhaps you can just dup() the socket? That's what the ref counter is for
> IIRC.
I already dup them for loop.create_server(sock=sock) and
loop.create_connection(sock=sock) cases. Duping for sock_recv & friends will
add too much ove
Yury Selivanov added the comment:
> OK, then maybe socket objects should get a dup() method that just
increments the ref counter, and that would be the public API you're looking
for?
"dup()" returns a new socket object, but here we only want to protect the
origina
Yury Selivanov added the comment:
> Note that a guard on socket objects can only solve part of the problem: in
> the case where i've seen this bug, it was with raw file descriptors from
> libcurl, and there's nothing python can do about that because there are no
> (
Change by Yury Selivanov :
--
components: asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: Support pathlib.Path in create_unix_connection; sock arg should
be optional
versions: Python 3.6, Python 3.7
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +4386
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32066>
___
___
Py
Yury Selivanov added the comment:
+1
--
___
Python tracker
<https://bugs.python.org/issue32069>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Yury Selivanov :
New changeset 423fd362f8e4d6c867a5afc8ac7cbeeb66cac19c by Yury Selivanov in
branch 'master':
bpo-32066: Support pathlib.Path in create_unix_connection; sock arg should be
optional (#4447)
https://github.com/python/cpyt
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:
> in order to write advanced Tasks there should be a way
> to throw custom exceptions into active Task.
> so it can react accordingly.
What is an "advanced" task? Why CancelledError is not enough? What
Yury Selivanov added the comment:
New changeset 431665bf1971e66c51f59abf0693f700ff7919e8 by Yury Selivanov
(AraHaan) in branch 'master':
bpo-32105: add asyncio.BaseEventLoop.connect_accepted_socket versionadded to
documentation. (#4491)
https://github.com/python/cpyt
Yury Selivanov added the comment:
New changeset d7ed48c2b8c11bb99da3661e8fe0bf5ae7f6b8d7 by Yury Selivanov (Miss
Islington (bot)) in branch '3.6':
bpo-32105: add asyncio.BaseEventLoop.connect_accepted_socket versionadded to
documentation. (GH-4491) (#4493)
https://github.com/pyth
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Yury Selivanov added the comment:
> ... result = list(await g(i) for i in range(3))
This is equivalent to this code:
async def ait():
for i in range(3):
v = await g(i)
yield v
result = list(ait())
Where 'ait' is an async generator functio
Yury Selivanov added the comment:
> Yury explained why this happens in https://bugs.python.org/issue32113
It happens because '(x for x in xs)' creates a synchronous generator. So when
there's an 'await' in it, it creat
Yury Selivanov added the comment:
It's also important to note, that in 3.7, this is legal:
def foo():
return (await x for x in xs)
Note that 'foo' is a regular function, not 'async def'.
--
___
Python tracker
Yury Selivanov added the comment:
> ... but [await x for x in xs] is still valid _only_ inside async def.
Yes, because it's computed right where it is defined.
a = [x for x in xs] # `a` is a list object
a = (x for x in xs) # `a` is a generator
Do you understand the di
Yury Selivanov added the comment:
> Well, after all I am thinking maybe it is indeed makes sense to ban `yield`
> inside both sync/async and both comprehensions/generator expressions.
I agree, as I can't imagine a real use case for
a = ((yield a) for a in as)
which is really
Yury Selivanov added the comment:
>> Do you understand the difference?
> Yury, sorry, but what is your problem? Have I said something about that this
> is bad. Your tone is clearly insulting, and this is not the first time. Maybe
> it makes sense to have some respect?
Sorry
Yury Selivanov added the comment:
> Yury OK, sorry then this is a misunderstanding from my side.
NP. Again, sorry if I sounded that way to you.
--
___
Python tracker
<https://bugs.python.org/issu
Change by Yury Selivanov :
--
nosy: -yselivanov
___
Python tracker
<https://bugs.python.org/issue32157>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> How will we guarantee that clients using the old `@coroutine`/`yield from`
> idiom still work?
They are fully supported now, but we can add a few tests to ensure we won't
break it.
--
___
Python trac
Yury Selivanov added the comment:
Andrew, would it be OK if I make a PR?
--
___
Python tracker
<https://bugs.python.org/issue32193>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
In general, implementing coroutines using 'yield' expressions (not 'yield
from'!) is slower than async/await, because the former approach needs a
trampoline to manage the stack, whereas CPython itself handles that for 'yield
from
Yury Selivanov added the comment:
> I agree that the PR I offers little (or no) improvement but I implore you to
> explore performance bottlenecks in async/await.
And I'm saying that there are no "performance bottlenecks in async/await".
async/await is *not* asyncio.
Yury Selivanov added the comment:
Also I suggest you to try uvloop. If your production code is still slower that
with asynq, I suggest you to profile it and post real profiles here. I just
don't think that asyncio.gather can be the main bottleneck you have, it must be
something
Change by Yury Selivanov :
--
assignee: yselivanov
components: asyncio
nosy: asvetlov, gvanrossum, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: Add asyncio.BufferedProtocol
versions: Python 3.7
___
Python tracker
<ht
New submission from Yury Selivanov :
A couple emails from async-sig for the context:
1. https://mail.python.org/pipermail/async-sig/2017-October/000392.html
2. https://mail.python.org/pipermail/async-sig/2017-December/000423.html
I propose to add another Protocol base class to asyncio
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +4658
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32251>
___
___
Py
Yury Selivanov added the comment:
I've made a PR that implements the change for selector_events.py.
With the change:
vanilla asyncio:120-135 Mb/s
vanilla asyncio/get_buffer: 220-230 Mb/s
uvloop: 320-330 Mb/s
uvloop/get_buffer: 600-650 Mb/s
Yury Selivanov added the comment:
> 1. What happens if size of read data is greater than pre-allocated buffer?
Let's say we have 2Kb of data in the socket's network buffer, and we only
preallocated 0.5Kb in our buffer. We will the receive 0.5Kb in our buffer,
'Proto
Yury Selivanov added the comment:
> Do you think it's possible to fold BufferedProtocol into Protocol?
It would be a backwards incompatible change :(
Coincidentally, there might be protocols that already implement 'get_buffer()'
and 'buffer_updated()' methods
Change by Yury Selivanov :
--
nosy: +asvetlov
___
Python tracker
<https://bugs.python.org/issue29883>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> This can make harder writing portable code that works in 2.7, 3.4 and 3.7.
asyncio for Python 3.4 is fairly outdated. Most of the async packages today
require 3.5+, as they usually use async/await syntax. I say this sort of
backwards compatibil
Change by Yury Selivanov :
--
nosy: -yselivanov
___
Python tracker
<https://bugs.python.org/issue32234>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Yury Selivanov :
--
components: asyncio
nosy: yselivanov
priority: normal
severity: normal
status: open
title: Fix linting errors in asyncio code; use f-strings consistently
versions: Python 3.7
___
Python tracker
<https://bugs.python.
Change by Yury Selivanov :
--
nosy: +asvetlov
___
Python tracker
<https://bugs.python.org/issue32262>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +4676
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32262>
___
___
Py
Yury Selivanov added the comment:
I think it's OK. I want asyncio code to stay modern and up to date. git blame
is not a problem here, as only one-two lines are changed per function. Code
consistency is more important.
--
___
Python tr
New submission from Yury Selivanov :
In many contexts `asyncio._get_running_loop()` is more useful than
`asyncio.get_event_loop()`. The former function is predictable and simple, the
latter can change its behaviour depending on the current policy and can even
create new event loops.
Both
Change by Yury Selivanov :
--
components: +asyncio
type: -> enhancement
versions: +Python 3.7
___
Python tracker
<https://bugs.python.org/issue32269>
___
_
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +4683
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32269>
___
___
Py
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Yury Selivanov added the comment:
New changeset 77106b2c21e59d0466742cc3afa50f9e8345e186 by Yury Selivanov (Pablo
Galindo) in branch 'master':
bpo-32114: Updated the documentation for get_event_loop to reflect the policy
change (#4510)
https://github.com/python/cpyt
Yury Selivanov added the comment:
New changeset 6370f345e1d5829e1fba59cd695c8b82c5a8c620 by Yury Selivanov in
branch 'master':
bpo-32262: Fix codestyle; use f-strings formatting where necessary. (#4775)
https://github.com/python/cpython/commit/6370f345e1d5829e1fba59cd695c8b
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
___
Python tracker
<https://bugs.python
Change by Yury Selivanov :
--
nosy: +asvetlov
___
Python tracker
<https://bugs.python.org/issue32272>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Yury Selivanov :
asyncio.async() is a deprecated alias for asyncio.ensure_future().
Since Python 3.7, async and await are proper keywords, and it is no longer
possible to use the function. I.e. both 'from asyncio import async' and
'asyncio.async(...)
Yury Selivanov added the comment:
The function has been deprecated since Python 3.4.4.
--
___
Python tracker
<https://bugs.python.org/issue32272>
___
___
Pytho
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +4685
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32272>
___
___
Py
New submission from Yury Selivanov :
asyncio.test_utils was never part of asyncio API and was never even documented.
It's purely due to historical reasons that test_utils.py is in the Lib/asyncio
directory.
--
components: asyncio
messages: 308008
nosy: asvetlov, yselivanov
pri
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +4686
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32273>
___
___
Py
Change by Yury Selivanov :
--
pull_requests: +4688
___
Python tracker
<https://bugs.python.org/issue32262>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
New changeset 19d0d5480931117d9e0bf396a0234707bbdaa494 by Yury Selivanov in
branch 'master':
bpo-32262: Fix f-string (#4787)
https://github.com/python/cpython/commit/19d0d5480931117d9e0bf396a02347
Yury Selivanov added the comment:
New changeset 9edad3c7011ccab0a66a065933abebf3288cf1a1 by Yury Selivanov in
branch 'master':
bpo-32272: Remove asyncio.async() function. (#4784)
https://github.com/python/cpython/commit/9edad3c7011ccab0a66a065933abeb
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Yury Selivanov added the comment:
New changeset 3e9751819ad13a965e8be13c1e5bc5a6811fe6b8 by Yury Selivanov in
branch 'master':
bpo-32273: Move asyncio.test_utils to test.test_asyncio (#4785)
https://github.com/python/cpython/commit/3e9751819ad13a965e8be13c1e5bc5
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Yury Selivanov added the comment:
> `asyncio._get_running_loop()` will be deprecated and removed in Python 3.9.
_get_running_loop() was left as-is.
--
___
Python tracker
<https://bugs.python.org/issu
Yury Selivanov added the comment:
> See https://eklitzke.org/goroutines-nonblocking-io-and-memory-usage for an
> interesting discussion of the drawbacks of some buffer handling idioms.
Thanks for the link!
It does make sense to use a pool of buffers for the proposed BufferedProtocol
Yury Selivanov added the comment:
>> Looks nice. Can it speed up aiohttp too?
> Yes.
> aiohttp uses own streams but public API and internal implementation are
> pretty close to asyncio streams.
> Moreover C accelerated HTTP parser should work with proposed BufferedProtocol
New submission from Yury Selivanov :
asyncio.get_event_loop(), and, subsequently asyncio._get_running_loop() are one
of the most frequently executed functions in asyncio. They also can't be sped
up by third-party event loops like uvloop.
When implemented in C they become 4x f
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +4719
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32296>
___
___
Py
Yury Selivanov added the comment:
First, I've no questions about the proposed implementation. It shouldn't have
performance impact when unawaited coroutine tracking is off, which is the
default. It will cause minimal overhead when the tracking is on, which is
fine. Adding
Yury Selivanov added the comment:
> send_ping() # don't care about result, forgot await
> # get collected
> await something_that_will_trigger_check_coros_weakreaf() # oh no !
I don't understand what you are trying to say with thi
Yury Selivanov added the comment:
New changeset a70232f28882d2fecb3ebe06643867701016070f by Yury Selivanov in
branch 'master':
bpo-32296: Implement asyncio.get_event_loop and _get_running_loop in C. (#4827)
https://github.com/python/cpython/commit/a70232f28882d2fecb3ebe06643867
801 - 900 of 3098 matches
Mail list logo
