Yury Selivanov added the comment:
> Yuri, I think we should deprecate explicit loop everywhere in non-deprecated
> asyncio API by Python 3.8.
+1
--
___
Python tracker
<https://bugs.python.org/i
New submission from Yury Selivanov :
When asyncio event loop is created in a non-main thread, it needs to initialize
a so called ChildWatcher for it (a helper object to intercept subprocesses
exits). Doing that requires to run code in the main thread.
I propose to add a 'sys.addpendin
Change by Yury Selivanov :
--
keywords: +patch
pull_requests: +13550
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/13656
___
Python tracker
<https://bugs.python.org/issu
Yury Selivanov added the comment:
> As to exposing Py_AddPendingCall() as sys.addpendingcall, that might be
> opening a can of worms. Injecting code into the eval loop at some arbitrary
> ("soon") future time requires care and the code isn't well exercised
&
Yury Selivanov added the comment:
Eric, regarding signals no longer using pending calls -- interesting, I'll take
a look. Thanks for pointing this out.
Sent from my iPhone
--
___
Python tracker
<https://bugs.python.org/is
Yury Selivanov added the comment:
> Sorry, that's how asyncio is designed.
Andrew, couldn't we provide a "stream.terminate()" method (not a coroutine)
that would do the following:
* close the transport
* set a flag in the protocol that the stream has been terminated.
Yury Selivanov added the comment:
> Not sure if we have to drop this warning, it enforces writing good code that
> controls all created resources lifecycle.
Right, maybe we add "transport.terminate()" as well? Synchronously &
immediately closing a transport is a val
Change by Yury Selivanov :
--
nosy: -yselivanov
___
Python tracker
<https://bugs.python.org/issue33694>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Yeah, we have the SSL reimplementation ready to be backported from uvloop to
cpython. Fantix, the original author, should be able to do that soon.
--
___
Python tracker
<https://bugs.python.org/issue37
Change by Yury Selivanov :
--
nosy: -yselivanov
___
Python tracker
<https://bugs.python.org/issue37213>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Victor, Andrew,
I'm not an expert in IOCP, but is it possible to implement add_reader/writer in
ProactorEventLoop? If there's no native API for that, I guess we can spawn a
thread with a 'select()' call to emulate this API?
Lukasz,
Yury Selivanov added the comment:
Andrew,
> Sorry, no. There is no way IIUC.
Well, in this case we should do that via a thread+select approach as I and Ben
suggested.
I can write some PoC code; will you have some time to polish it and commit it?
(I'm OOO and don't have a wi
Yury Selivanov added the comment:
+1 to what Ben said.
Andrew,
> The proposal looks like a very dirty hack and smells as it is.
I wonder why are you feeling like that about this idea. I don't think this is
a hack at all. There's no native API, so we're forced to us
Yury Selivanov added the comment:
> I hear you on the semantic confusion, but is a single check at definition
> time really that expensive?
Do you know how to make that single check 100% reliable?
--
___
Python tracker
<https://bugs.p
Yury Selivanov added the comment:
> I think a simple iscoroutinefunction check will be pretty close to 100%
> matching what users expect.
Yes, "pretty close", but not reliable. :) E.g. I can easily design a decorator
that when applied first would break the proposed isc
Yury Selivanov added the comment:
Yes, this is a known limitation of asyncio -- keyboardinterrupt exceptions
kills the loop rather abruptly. One way to handle this is to use
'signal.signal' for sigint to raise custom exception instead of
keyboar
Yury Selivanov added the comment:
New changeset f3cffd2b7879d209f982de899b782fb89cfc410a by Yury Selivanov (Dino
Viehland) in branch 'master':
bpo-30604: clean up co_extra support (#2144)
https://github.com/python/cpython/commit/f3cffd2b7879d209f982de899b782f
Yury Selivanov added the comment:
It doesn't need to be, it's only for 3.6
--
___
Python tracker
<http://bugs.python.org/issue30604>
___
___
Python-b
Yury Selivanov added the comment:
Closing the issue. Thank you Dino for working on this!
--
resolution: -> fixed
stage: backport needed -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
> The approach in Dan's patches looks sane to me and I agree the issue needs
> fixing. Dan, would you like to submit a PR for this? We're using Github for
> patch submissions now.
Mind that the patch is very outdated and we already h
Yury Selivanov added the comment:
> Possible answer: have a global WeakSet of event loops. In the child fork
> handler, iterate over all event loops and "break" those that have already
> been started.
We can do this but
Yury Selivanov added the comment:
> It seems there's a check in the top-level get_event_loop() function but not
> in the DefaultEventLoopPolicy.get_event_loop() method.
Yes, as users aren't supposed to work with policies directly.
> (also: wow, that stuff is complicated)
Yury Selivanov added the comment:
> A compromise for the short term would be to detect fork in debug mode
and raise an exception, and explain how to fix such bug. What do you
think?
I'd prefer to fix it properly in 3.7.
--
___
Python tracke
Yury Selivanov added the comment:
> I'm not sure why it would be debug-only. You usually don't fork() often, and
> you don't have many event loops around, so the feature sounds cheap.
I think you're right. If it's low or zero overhead we can
Yury Selivanov added the comment:
> Yury, based on the most recent comments, can this issue be closed now?
Not sure, I'm reviewing the patch for #30698, let's see if it fixes the problem.
--
___
Python tracker
<http://bugs.pytho
Changes by Yury Selivanov :
--
pull_requests: +2640
___
Python tracker
<http://bugs.python.org/issue30828>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
New changeset 833a3b0d3707200daeaccdd218e8f18a190284aa by Yury Selivanov in
branch 'master':
bpo-30828: Fix out of bounds write in `asyncio.CFuture.remove_done_callback()
(#2569)
https://github.com/python/cpyt
Changes by Yury Selivanov :
--
pull_requests: +2660
___
Python tracker
<http://bugs.python.org/issue30828>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
New changeset aaa4f991518611d101fba1ef3ecb18d7b385ad5b by Yury Selivanov in
branch '3.6':
[3.6] bpo-30828: Fix out of bounds write in
`asyncio.CFuture.remove_done_callback() (GH-2569) (#2590)
https://github.com/python/cpyt
Yury Selivanov added the comment:
> But IMHO the example it's just that an example, if the connection at
some point was not broken/closed/... and some data came into the
buffer, this data should be put available for the user.
In my experience, you never want to recover any data fro
Yury Selivanov added the comment:
I looked at the PR and it looks good. The intent is also clear. But the idea of
delaying exceptions in StreamReader read methods still feels finicky.
To go forward with this we need more examples than just nodejs. And it doesn't
really matter what tri
Yury Selivanov added the comment:
> Better than trying to detect IPv6 compatibility beforehand would probably to
> recognize the error and simply ignore it.
+1
--
___
Python tracker
<http://bugs.python.org/i
Yury Selivanov added the comment:
Well, don't use "print(e)" when you are printing errors in in Python. This is
pretty standard behaviour for all Python code, not just asyncio. A lot of code
in stdlib raises exceptions, almost none allows to
Yury Selivanov added the comment:
> Yes, I agree with you about my weird way of debugging. But anyway, changing
> API with adding ability to pass actual cause would be welcome.
I'm not opposed to the idea, btw. If we do decide to add an argument to
'cancel', we probably s
Yury Selivanov added the comment:
> Will it cancel whole chain of depending futures in a RIGHT way ?
I was thinking about this:
def Future.set_exception(exc):
if isinstance(exc, asyncio.CancelledError):
return self._cancel(exc)
# here goes old code
def Future.can
Yury Selivanov added the comment:
Interesting. A code to reproduce this crash would help tremendously. So far
this is the first time I hear about this crash.
--
nosy: +inada.naoki
___
Python tracker
<http://bugs.python.org/issue31
Yury Selivanov added the comment:
> so looks like disabling the _asyncio module just caused the crash to happen
> less often, closing and will continue investigating after a get a core file
Interesting. So it crashes even with pure Python Future/Task implementations?
Another idea to
Yury Selivanov added the comment:
Thank you for trying to get to the bottom of this!
--
___
Python tracker
<http://bugs.python.org/issue31061>
___
___
Python-bug
Yury Selivanov added the comment:
>ok got a full debug core file, let me know what other information I can
>provide.
Thank you. Does the crash happen with python versions of Tasks and Future?
--
___
Python tracker
<http://bugs.p
Yury Selivanov added the comment:
Alexander, I think this is it, you found it! Can you open a PR against master
with a fix? I'll review & merge it.
--
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Thank you, Alexander. Bugs like this are notoriously hard to fix, you saved us
from hours, if not days, of debugging.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python track
Changes by Yury Selivanov :
--
nosy: -yselivanov
___
Python tracker
<http://bugs.python.org/issue31113>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
pull_requests: +3104
___
Python tracker
<http://bugs.python.org/issue31179>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Yury Selivanov:
It's possible to significantly improve performance of shallow dict copy.
Currently, PyDict_Copy creates a new empty dict object and then inserts
key/values into it one by one.
My idea is to simply memcpy the whole keys/items region and do the nece
Yury Selivanov added the comment:
>> PyDict_Copy creates a new empty dict object and then inserts key/values into
>> it one by one.
> Why not creating a "preallocated" dict in that case? _PyDict_NewPresized()
I don't think it's related to the proposed pa
Yury Selivanov added the comment:
> Why "del" doesn't compact the dict?
This is a good question, btw.
--
___
Python tracker
<http://bugs.
Yury Selivanov added the comment:
> I like idea.
> One worrying point is how to deal with dirty dict.
> How about do it only when ma_used == keys->dk_nentries?
I've added this check. See the updated PR.
> The PR changes the behavior. Currently the effect of copying is co
Yury Selivanov added the comment:
Adding INADA, he is a co-author/reviewer of that code.
--
nosy: +inada.naoki
___
Python tracker
<http://bugs.python.org/issue31
Yury Selivanov added the comment:
Huge thanks, Serhiy, btw.
--
___
Python tracker
<http://bugs.python.org/issue31185>
___
___
Python-bugs-list mailing list
Unsub
Yury Selivanov added the comment:
> "reference leaks" oh? our Refleaks buildbots didn't catch them.
The test suite for Tasks and Futures is pretty extensive, but it obviously
doesn't cover some obscure use cases.
+1 to make sure that any refleak that was disco
Yury Selivanov added the comment:
> Or am I missing something subtle here?
We'll need to make any() and all() coroutines. Not simple coroutines though,
but weird "hybrid" functions that preserve the old semantics + implement async
stuff.
I don't think this is a ve
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue14976>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
An idea from the blog post: if we rewrite queue in C it will use the GIL as a
lock which will fix this particular bug. I can make a patch.
--
status: closed -> open
___
Python tracker
<http://bugs.pyth
Yury Selivanov added the comment:
> Here is a pure Python PoC patch that allows unbounded Queue and LifoQueue to
> have reentrant put().
Is it guaranteed that the GC will happen in the same thread that is holding the
lock? IOW will RLock help with all GC/__del__ deadlocking sce
Yury Selivanov added the comment:
> I'm not sure about type() to get a class object and calling __aenter__,
> __aexit__ through it: that makes it hard to mock these classes as Mock's
> spec= relies on __class__ and type() seem to ignore it (learned it a hard way.
Looking up
Yury Selivanov added the comment:
> I started a local PR at https://github.com/ncoghlan/cpython/pull/1/files to
> explore what this might look like in practice.
Looks good to me.
> I'm less sure about __delegated_to__/__returns_to__, since we don't have
> *any* code i
Yury Selivanov added the comment:
>> but at the same time rejected by the 'async with' statement.
> Perhaps unittest.mock (or type) needs to be adjusted to allow mocking via
> spec= without subclassing?
Maybe. You should try to find discussions around this topic on pyt
Yury Selivanov added the comment:
> I'm not convinced that the PR is worth it. 3% is not interesting on a micro
> benchmark.
I found a small issue in the PR (left a comment in the PR).
I think using a tuple is still a good idea (even if the speedup is tiny)
because logically, both
Yury Selivanov added the comment:
> Or is there an issue in my benchmark?
Yes. The correct benchmark would be to measure `get_event_loop` performance
from *within* a running event loop.
--
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
New changeset 80bbe6a7b67f33d0d0976bb8e3e5ba26b6b0e626 by Yury Selivanov
(jimmylai) in branch 'master':
bpo-31350: Optimize get_event_loop and _get_running_loop (#3347)
https://github.com/python/cpython/commit/80bbe6a7b67f33d0d0976bb8e3e5ba
Yury Selivanov added the comment:
Andrew, looks like it. You can take a look if you want (I don't have time to
work on this right now).
--
___
Python tracker
<https://bugs.python.org/is
Yury Selivanov added the comment:
I looked at the PR, and I'm not so sure about this change. In short, it can be
viewed as a backwards incompatible change to asyncio.gather.
Guido, what do you think?
--
nosy: +gvanrossum
___
Python tracker
&
Yury Selivanov added the comment:
> it's expected that the sleep time may be *more* than asked for, but not less
> than.
Exactly, and asyncio tries to ensure that. It looks like
"time.get_clock_info('monotonic').resolution" lies about monotonic clock
resolut
Yury Selivanov added the comment:
So here's the relevant piece of code:
end_time = self.time() + self._clock_resolution
while self._scheduled:
handle = self._scheduled[0]
if handle._when >= end_time:
break
Yury Selivanov added the comment:
> The performance issue was that the asyncio core loop was running in a loop
but did nothing because of time rounding. When the next event was in a few
nanoseconds, the e event burnt the CPU during seconds.
It can be 15 ms on Windows or 1 ms when using p
Yury Selivanov added the comment:
> I'm afraid I no longer have all the details of this design in my head, and I
> have no idea what the fix does (and no time to read up on everything).
Let's say we have three tasks: t1, t2, t3. Then we use gather on them:
await gather(t1
Yury Selivanov added the comment:
Do you have a use case where this optimization is important?
--
___
Python tracker
<https://bugs.python.org/issue31556>
___
___
Yury Selivanov added the comment:
I think this is a backwards incompatible change and thus will be rejected.
Currently there's a guarantee that "wait_for" can throw a TimeoutError *only*
when when you await it.
fut = wait_for(something, 0)
# some important code
tr
Yury Selivanov added the comment:
You're right! Let's work on the PR then, I've left a review comment.
--
___
Python tracker
<https://bugs.pyt
Change by Yury Selivanov :
--
nosy: -yselivanov
___
Python tracker
<https://bugs.python.org/issue21314>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
-1 on this; there is no clear win in doing this refactoring, only a hard to
estimate chance of making a regression.
Yahya, feel free to tackle other asyncio bugs or improvements, this one is just
something that we aren't comfortable doing righ
Yury Selivanov added the comment:
Please don't merge the PR. I'll need some time to think about this before
giving it a green light.
--
___
Python tracker
<https://bugs.python.o
Yury Selivanov added the comment:
Dima, we'll likely address this in 3.8, when we land new SSL implementation.
Meanwhile you can use uvloop where all these bugs should be fixed.
--
___
Python tracker
<https://bugs.python.org/is
Yury Selivanov added the comment:
New changeset e3666fc8effb05b555121f4ab7388df59e21f8b4 by Yury Selivanov
(Hrvoje Nikšić) in branch 'master':
bpo-35465: Document _UnixSelectorEventLoop.add_signal_handler. (GH-11145)
https://github.com/python/cpyt
Change by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
___
Python tracker
<https://bugs.python
Yury Selivanov added the comment:
New changeset 12f3979b3807b448ca070b44bbc1597cf800f8a4 by Yury Selivanov (Miss
Islington (bot)) in branch '3.7':
bpo-35465: Document _UnixSelectorEventLoop.add_signal_handler. (GH-11145)
(GH-11221)
https://github.com/python/cpyt
Yury Selivanov added the comment:
+1. I've tried to use `field(frozen=True)` today and was surprised it's not
supported.
--
nosy: +yselivanov
___
Python tracker
<https://bugs.python.o
Yury Selivanov added the comment:
Very interesting. Thanks for reporting this issue. I'll definitely take a look
at this before 3.8 is released. For 3.7 you'll likely have to find a
workaround.
--
___
Python tracker
<https://bu
Yury Selivanov added the comment:
> You are right, the issue is "theoretical", I didn't see problems with current
> implementation.
> The self-pipe buffer is pretty big, a chance to reach its limit is relatively
> low.
Actually, I disagree. The problem manif
Change by Yury Selivanov :
--
stage: resolved -> needs patch
___
Python tracker
<https://bugs.python.org/issue35749>
___
___
Python-bugs-list mailing list
Un
Yury Selivanov added the comment:
Please submit a PR!
--
components: +asyncio -Documentation
keywords: +easy
nosy: +asvetlov, yselivanov
___
Python tracker
<https://bugs.python.org/issue35
Yury Selivanov added the comment:
Christian, do you think the sessions support shouldn't be added to asyncio in
3.8?
--
___
Python tracker
<https://bugs.python.org/is
Yury Selivanov added the comment:
This is a backwards incompatible change, unfortunately. Wait for the new
TaskGroups API that will resolve this issue.
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
_
Yury Selivanov added the comment:
> One reason why Task.cancel() is an incomplete replacement for
> Task.set_exception() is that you don't have an easy way to communicate why
> the task was ended.
The result of the Task is bound to the result of the coroutine it wraps. If
Yury Selivanov added the comment:
>> There's no clear reason to complicate the Task<->coroutine relationship by
>> allowing to inject arbitrary exceptions into running coroutines.
> My comment was more about CancelledError rather than arbitrary exceptions.
> Yo
Yury Selivanov added the comment:
Yes, closing the issue. Thanks, Ned!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Yury Selivanov added the comment:
I'm not sure we need this feature TBH.
--
___
Python tracker
<http://bugs.python.org/issue29471>
___
___
Python-bugs-list m
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Xiang, can you make a PR?
--
___
Python tracker
<http://bugs.python.org/issue24329>
___
___
Python-bugs-list mailing list
Unsub
Changes by Yury Selivanov :
--
versions: -Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue24329>
___
___
Python-bugs-list mailin
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29704>
___
___
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 3.7
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
> Thanks for the report and PR, but your fix is not obviously correct.
Not for this particular asyncio method though, see asyncio PEP [1]. But there's
an actual bug in the PR, instead of returning `None` we should return `default`.
[
Yury Selivanov added the comment:
> Case (c) sidesteps the above questions.
I like the (c) option. I don't think we should use logging/warnings here, as
they can produce unwanted noise that few know how to silence.
When the list of errors is passed as a second argument to the except
Yury Selivanov added the comment:
This is a new feature, so we can only push it to 3.7.
--
nosy: +brett.cannon, haypo
versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue29
Changes by Yury Selivanov :
--
pull_requests: +533
___
Python tracker
<http://bugs.python.org/issue29600>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
What a bizarre bug. Created a PR with a fix.
Nathaniel, please put me in a nosy list when you submit issues about
generators/coroutines.
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.
Changes by Yury Selivanov :
--
pull_requests: +534
___
Python tracker
<http://bugs.python.org/issue29742>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
pull_requests: +535
___
Python tracker
<http://bugs.python.org/issue29742>
___
___
Python-bugs-list mailing list
Unsubscribe:
301 - 400 of 3129 matches
Mail list logo
