Yury Selivanov <yseliva...@gmail.com> added the comment:
"if not block:" means EOF and replacing it with "if len(block) < self._limit:"
would break everything.
There might be another bug here (with TTY) or, maybe, there's a bug in
pty_test.py. For example
Yury Selivanov <yseliva...@gmail.com> added the comment:
Terry, you somehow deleted Christian from the nosy list.
Christian,
> It's failing reproducible with OpenSSL 1.1.1 and TLS 1.3 enabled. I haven't
> seen it failing with TLS 1.2 yet.
On Linux or Windows?
---
Yury Selivanov <yseliva...@gmail.com> added the comment:
> But in msg317468 Victor asserts that it sometimes fails on Linux, too?
Hm, I missed that. I'll definitely take a look.
--
___
Python tracker <rep...@bugs.python.org>
<https
Yury Selivanov <yseliva...@gmail.com> added the comment:
Last time I looked into this I couldn't reproduce the failures on my Windows 10
VM, so it seems like an AppVeyor-specific problem. I'll take another look on
Monday.
Andrew, if you have a Windows environment, could you please try
Yury Selivanov <yseliva...@gmail.com> added the comment:
Thanks, Ned!
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33654>
___
Yury Selivanov <yseliva...@gmail.com> added the comment:
Setting "release blocker" to get Ned's attention.
--
priority: high -> release blocker
___
Python tracker <rep...@bugs.python.org>
<https:
Change by Yury Selivanov <yseliva...@gmail.com>:
--
keywords: +patch
pull_requests: +6764
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Yury Selivanov <yseliva...@gmail.com>:
1. asyncio.BufferedProtocol is a new Python 3.7 *provisional* API.
2. asyncio.Transport.set_protocol() doesn't support switching between Protocol
and BufferedProtocol.
3. Because of (2), another *new* Python 3.7 API "loo
Yury Selivanov <yseliva...@gmail.com> added the comment:
IMO this particular patch is OK and should go in. I'll take another look at
the PR in a few days (and will run some benchmarks myself before making the
decision).
--
___
Python tracke
New submission from Yury Selivanov <yseliva...@gmail.com>:
Doing that will break subprocesses.
--
components: asyncio
messages: 317717
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Prohibit adding a signal handler for SIGCHLD
versions: Pyth
New submission from Yury Selivanov <yseliva...@gmail.com>:
An overhaul of asyncio documentation is long overdue. Here's the structure for
it that I have in mind:
- Introduction
(what is asyncio and async/await)
- A quick tutorial
(show how to use asyncio.run() and basic function
Yury Selivanov <yseliva...@gmail.com> added the comment:
Closing this issue. I'll open a new one for the planned asyncio docs overhaul.
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Pyth
Yury Selivanov <yseliva...@gmail.com> added the comment:
If this issue isn't yet fixed could you please submit a PR?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
Andrew, what are your thoughts on this one?
--
nosy: +asvetlov
versions: +Python 3.8 -Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
Closing this issue as I, personally, don't see this happening and there's no
point in keeping it open.
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Yury Selivanov <yseliva...@gmail.com> added the comment:
Is this issue resolved now, or do we need to work on this?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
Closing this one. I don't see us adding Future.then. Feel free to discuss on
the MLs.
--
components: +asyncio -Library (Lib)
nosy: +asvetlov, yselivanov
resolution: -> rejected
stage: patch review -&
Yury Selivanov <yseliva...@gmail.com> added the comment:
Should this issue be closed now?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
Not at my computer right now, can do it tomorrow.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
I'm OK to skip it for now. Writing functional tests is super hard because some
buildbots are super slow and unpredictable.
--
___
Python tracker <rep...@bugs.python.or
Yury Selivanov <yseliva...@gmail.com> added the comment:
Thanks, I'll look into adding ag_running properly.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Yury Selivanov <yseliva...@gmail.com>:
--
assignee: -> yselivanov
components: +Interpreter Core -asyncio
priority: normal -> high
versions: +Python 3.8
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
Yury Selivanov <yseliva...@gmail.com> added the comment:
Thanks Jan. Thanks a lot for a short script to reproduce this bug.
The actual problem here is that asynchronous generators don't control their
'asend' and 'athrow' coroutines in any way. So if you have two of them
iterating *in pa
Yury Selivanov <yseliva...@gmail.com> added the comment:
> Then we should find what callable is NULL and fix the place where it is
> called. _PyObject_FastCallDict() should never be called with NULL.
My understanding is that the interpreter is being shutdown and half of the
objec
Yury Selivanov <yseliva...@gmail.com> added the comment:
> Is the problem because traceback_extract_stack is NULL?
It's not NULL, it's just a broken reference at that point.
--
___
Python tracker <rep...@bugs.python.org>
<https
Change by Yury Selivanov <yseliva...@gmail.com>:
--
type: -> crash
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33623>
___
__
Change by Yury Selivanov <yseliva...@gmail.com>:
--
components: +asyncio
nosy: +asvetlov
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Yury Selivanov <yseliva...@gmail.com>:
--
keywords: +patch
pull_requests: +6710
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Yury Selivanov <yseliva...@gmail.com>:
Originally reported in https://github.com/MagicStack/uvloop/issues/143
Future.__init__ shouldn't try to capture the current traceback if the
interpreter is being finalized.
--
messages: 317437
nosy: yselivanov
priority:
Yury Selivanov <yseliva...@gmail.com> added the comment:
Echo server is usually a good enough microbenchmark (you can use benchmarks
from uvloop/examples). Repeatedly calling call_soon would also be an
interesting micro-benchmark but less important (unless it shows that call_soon
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset 28b9178023a445b1da2694774c265cd4b7a244ec by Yury Selivanov in
branch 'master':
bpo-32436: Document PEP 567 changes to asyncio. (GH-7073)
https://github.com/python/cpython/commit/28b9178023a445b1da2694774c265cd4b7
Change by Yury Selivanov <yseliva...@gmail.com>:
--
pull_requests: +6703
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32436>
___
New submission from Yury Selivanov <yseliva...@gmail.com>:
I don't see it documented that dicts preserve insertion order. 3.7 what's new
points to [1], but that section doesn't have a "version changed" tag.
IMO, [1] should have two version changed tags: one for 3.6, and on
Yury Selivanov <yseliva...@gmail.com> added the comment:
> I suggest that asyncio should be stricter about this error and that methods
> and functions that operate on the event loop, such as call_soon, call_later,
> create_task, ensure_future, and close, should all call _chec
Yury Selivanov <yseliva...@gmail.com> added the comment:
This is such a great idea. +1 from me.
--
nosy: +yselivanov
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset b2f5f59ae15564b991f3ca4850e6ad28d9faacbc by Yury Selivanov (Elvis
Pranskevichus) in branch 'master':
bpo-33592: Document the C API in PEP 567 (contextvars) (GH-7033)
https://github.com/python/cpython/
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset 15f3d0cc7660ee62c7a1c0420afaee18c26a2a1f by Yury Selivanov (Elvis
Pranskevichus) in branch '3.7':
[3.7] bpo-32996: The bulk of What's New in Python 3.7 (GH-6978). (GH-6998)
https://github.com/python/cpython/
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset 63536bd286097e770909052052a21804a5e09b66 by Yury Selivanov (Elvis
Pranskevichus) in branch 'master':
bpo-32996: The bulk of What's New in Python 3.7 (GH-6978)
https://github.com/python/cpython/
Yury Selivanov <yseliva...@gmail.com> added the comment:
The syntax for async lambdas doesn't look nice and I, personally, don't see
that many use cases for them to justify adding new syntax. And this would need
a new PEP.
I suggest to start a discussion on the Python-ideas mailin
Change by Yury Selivanov <yseliva...@gmail.com>:
--
nosy: -yselivanov
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32604>
___
Yury Selivanov <yseliva...@gmail.com> added the comment:
I like the idea. Let's revisit it after Python 3.7 is released.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
> Deprecating Event.wait would be incorrect because Event was designed to mimic
> the threading.Event class which has a (blocking) wait() method[1].
This is rather important. I'd like to continue maintaining this similar
Yury Selivanov <yseliva...@gmail.com> added the comment:
This isn't a priority now, so let's postpone the discussion on this until 3.7
is released.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
> Did you mean {} for the outer brackets intead of []?
Yes, my bad.
> All of these should only be allowed inside 'async def' though, right?
Yep, except async generator expressions which are allowed to appear in
synchron
Yury Selivanov <yseliva...@gmail.com> added the comment:
[Serhiy]
> But asynchronous comprehensions should behave the same way as 'await'. I
> think that a comprehension should be made implicitly asynchronous if any of
> inner expressions contains explicit or implic
Yury Selivanov <yseliva...@gmail.com> added the comment:
Thank you, Tom!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Yury Selivanov <yseliva...@gmail.com> added the comment:
Thanks so much!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset a93a663d6c2fdfbddbda9729c96e2737c0012522 by Yury Selivanov (Zsolt
Dollenstein) in branch '3.7':
[3.7] bpo-33363: raise SyntaxError for async for/with outside async functions
(GH-6616). (GH-6619)
https://github.com/
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset e2396506606115e785c94ec129eb86e2ed0aa744 by Yury Selivanov (Zsolt
Dollenstein) in branch 'master':
bpo-33363: raise SyntaxError for async for/with outside async functions (#6616)
https://github.com/python/cpython/
Yury Selivanov <yseliva...@gmail.com> added the comment:
I like what you propose. Can you submit a PR? :)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
Wow, this is a regression that has to be fixed in 3.7.
--
nosy: +ned.deily, yselivanov
priority: normal -> release blocker
___
Python tracker <rep...@bugs.python.org>
<https
Yury Selivanov <yseliva...@gmail.com> added the comment:
Yep, I think this is a good fix!
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
> I like the idea of having an argument to construct the CancelledError with,
> but I like even more the ability to tell the exception that will be raised to
> have the traceback of the point where the task was originally
Yury Selivanov <yseliva...@gmail.com> added the comment:
> Yuri, what do you think about?
I plan to use contextvars module to introduce a full-blown tracing API to
asyncio to selectively log events like tacks creations, event loop switching,
IO done by transports etc.
Yury Selivanov <yseliva...@gmail.com> added the comment:
3.5 is in security fixes only, so don't bother.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
> PR 6352 smells like a bug fix to me and I think it should be OK for 3.7.0b4.
Can we backport it to 3.6 too?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Yury Selivanov <yseliva...@gmail.com> added the comment:
> Even without context chaining, it seems to me that nesting of class
> definitions could be handled by making the context variable a list of cell
> objects and having type.__new__ look at the final entry rather than the
Yury Selivanov <yseliva...@gmail.com> added the comment:
This would work only if we had chained contexts from PEP 550. With PEP 567,
swapping the current Context in boundmethods would cause all methods to lose
the context that the user wanted them
Yury Selivanov <yseliva...@gmail.com> added the comment:
> I suppose that it would also be difficult to get buy-in for a feature like
> this from the different frameworks?
Maybe :) Ideally, asyncio programs should not depend on how exactly tasks ar
Yury Selivanov <yseliva...@gmail.com> added the comment:
> Does this mean that GC uses most part of CPU time so the loop blocks?
GC stops all Python code in the OS process from running. Because of the GIL
code in threads will obviously be stopped too. This is true for both CPython
Yury Selivanov <yseliva...@gmail.com> added the comment:
> 'events.AbstractEventLoop.run_one_step()'
This is highly unlikely to ever happen. It's hard to define what one iteration
of an event loop is, and it would be even harder to get that agreement for all
frameworks/ev
Yury Selivanov <yseliva...@gmail.com> added the comment:
Yeah, I think your best option would be to use `set_write_buffer_limits(0, 0)`.
You don't need asyncio flow control anyways, as AMQP protocol is unlikely to
generate any pressure on IO b
Yury Selivanov <yseliva...@gmail.com> added the comment:
We'll likely add 'write_buffer_drained' callback method to `asyncio.Protocol`
in 3.8. In the meanwhile, the only option would be using `_make_empty_waiter`
in 3.7, or set_write_buffer_limits(0, 0).
What's your use case, by t
Yury Selivanov <yseliva...@gmail.com> added the comment:
The "blocking" you observe is caused by Python GC. If I add "import gc;
gc.disable()" the warnings disappear.
--
___
Python tracker <rep...@bugs.python.
Yury Selivanov <yseliva...@gmail.com> added the comment:
Well, there's nothing we can do here, it's just a lot of work for a
single-threaded process to get a 1 tasks going. You'll get the same
picture in any other async Python fra
Yury Selivanov <yseliva...@gmail.com> added the comment:
> - I would say event loop per class. If someone really needs event loop per
> method, they can create separate classes per method. It's ugly, but
> effective.
+1.
- We should have an async setUp capability. May
Yury Selivanov <yseliva...@gmail.com> added the comment:
First, John and Peter, let's not have two competing PRs. I'd prefer to have
only one to make things easier to review. So far it looks like Peter's is
slightly more developed. And this also seems to be a complex issue, so t
Yury Selivanov <yseliva...@gmail.com> added the comment:
Thanks so much for looking into this, Serhiy!
> 2. StopAsyncIteration is dynamically looked up in globals. If set the global
> StopAsyncIteration or delete it from builtins (for example at the shutdown
> stage), this
Change by Yury Selivanov <yseliva...@gmail.com>:
--
nosy: -yselivanov
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32758>
___
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset 12f74d8608c15cacd9d5786524e2be9ca36f007e by Yury Selivanov
(Nathan Henrie) in branch '3.6':
bpo-32517: fix test_read_pty_output() hangs on macOS 10.13.2+ (GH-6037)
https://github.com/python/cpython/
Yury Selivanov <yseliva...@gmail.com> added the comment:
> That code does not seem to work for me:
> https://gist.github.com/PetterS/f684095a09fd1d8164a4d8b28ce3932d
> I get "RuntimeWarning: coroutine 'test_async_with_mock' was never awaited"
> @mock.patch need
Yury Selivanov <yseliva...@gmail.com> added the comment:
> I'm really not seeing what a separate class buys you.
I already mentioned in my previous comments that adding async support to
unittest.TestCase would require us to add a metaclass to it, which is
potentially a backwards inc
Yury Selivanov <yseliva...@gmail.com> added the comment:
> Doesn't that break when, for example, test methods are decorated with
> unittest.mock.patch?
No, it shouldn't break them if you wrap async methods carefully.
Here's a metaclass that I wrote recently doing just
Yury Selivanov <yseliva...@gmail.com> added the comment:
> How is a separate base class better? :)
It's very explicit that way.
Also, I personally subclassed TestCase in many of my projects specifically to
add async support. To do that you have to use a metaclass to scan class'
Change by Yury Selivanov <yseliva...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Yury Selivanov <yseliva...@gmail.com> added the comment:
> Instead of a separate base class, what about an overridable
> `coroutine_runner` attribute that defaults to `asyncio.run`?
How is that better?
--
___
Python tracker <rep...@
Yury Selivanov <yseliva...@gmail.com> added the comment:
I think the right approach would be to add an new base TestCase class:
AsyncioTestCase. There other frameworks that have different event loop
implementations, so we can't assume that an `async def` test should always be
ex
Yury Selivanov <yseliva...@gmail.com> added the comment:
This is a duplicate of issue 32972. Let's move the discussion there.
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder: -> unittest.TestCase
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset 8a387219bdfb6ee34928d6168ac42ca559f11c9a by Yury Selivanov in
branch 'master':
bpo-33009: Fix inspect.signature() for single-parameter partialmethods.
(GH-6004)
https://github.com/python/cpython/
Yury Selivanov <yseliva...@gmail.com> added the comment:
I think the right approach would be to add an new base TestCase class:
AsyncioTestCase.
And you should use the `asyncio.run` function to run the coroutine.
--
nosy: +yselivanov
___
Yury Selivanov <yseliva...@gmail.com> added the comment:
Yeah, that assertion needs to be tweaked a little bit. Created a PR.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Yury Selivanov <yseliva...@gmail.com>:
--
keywords: +patch
pull_requests: +5769
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Yury Selivanov <yseliva...@gmail.com> added the comment:
FYI I found out about this refleak from
https://mail.python.org/pipermail/python-checkins/2018-February/153907.html
So it's definitely not Mac OS X specific thing.
--
___
Python tracke
Yury Selivanov <yseliva...@gmail.com> added the comment:
Eric, it looks like your recent commit introduced a refleak. We need to fix it
before beta2.
~/d/p/cpython (master $) » ./python.exe -m test -R3:3 test_multiprocessing_fork
Run tests sequentially
0:00:00 load avg: 2.5
Yury Selivanov <yseliva...@gmail.com> added the comment:
I'm still not sure whether we should enable this optimization or not.
I haven't ever seen this pattern used in any Python code I worked with, so I
suspect it's quite a rare hack. Giving it a fast-path would give this pattern
Yury Selivanov <yseliva...@gmail.com> added the comment:
With the basic documentation committed, I'm now closing this issue.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep.
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset bd093355a6aaf2f4ca3ed153e195da57870a55eb by Yury Selivanov in
branch 'master':
bpo-32436: Add docs for contextvars (#5685)
https://github.com/python/cpython/commit/bd093355a6aaf2f4ca3ed153e195da5787
Change by Yury Selivanov <yseliva...@gmail.com>:
--
pull_requests: +5481
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32436>
___
Change by Yury Selivanov <yseliva...@gmail.com>:
Removed file: https://bugs.python.org/file47441/le_meme.jpg
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Yury Selivanov <yseliva...@gmail.com> added the comment:
le_meme.jpg is a pretty common facial expression when one debugs
locks/conditions, so let's not attach it in the future :) We try to keep the
bug tracker free of unnecessary information.
As for the bug—please submi
Change by Yury Selivanov <yseliva...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset 0442599961f966a3dc7f3fe6a3c0d5765fcf2082 by Yury Selivanov (Miss
Islington (bot)) in branch '3.7':
bpo-32221: makeipaddr(): remove interface part + speedup (GH-5449) (GH-5449)
(#5641)
https://github.com/python/c
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset 7766b96ab80b04509bbac708ee5ecf3c1c5934fc by Yury Selivanov
(Коренберг Марк) in branch 'master':
bpo-32221: makeipaddr(): remove interface part + speedup (GH-5449) (#5449)
https://github.com/python/cpython/
Yury Selivanov <yseliva...@gmail.com> added the comment:
I think it's a good idea and I wanted to implement it by copying TaskGroups
from curio in 3.7. But then I saw Trio's nurseries and I have a few ideas
about slightly different design inspired by both curio and Trio :)
I have som
Change by Yury Selivanov <yseliva...@gmail.com>:
--
nosy: -yselivanov
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32753>
___
Yury Selivanov <yseliva...@gmail.com> added the comment:
Thank you, Bar!
Looking forward to see more contributions to asyncio from you!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Pyth
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset 7e4cf8e95d2971ae0d5fb417152183070184293f by Yury Selivanov (Bar
Harel) in branch '3.6':
[3.6] bpo-32734: Fix asyncio.Lock multiple acquire safety issue (GH-5466)
(#5502)
https://github.com/python/cpython/
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset 2b5937ec0ae88cd0b4cc0c8534f21c435ee94662 by Yury Selivanov (Miss
Islington (bot)) in branch '3.7':
bpo-32734: Fix asyncio.Lock multiple acquire safety issue (GH-5466) (#5501)
https://github.com/python/cpython/
Yury Selivanov <yseliva...@gmail.com> added the comment:
New changeset 2f79c014931cbb23b08a7d16c534a3cc9607ae14 by Yury Selivanov (Bar
Harel) in branch 'master':
bpo-32734: Fix asyncio.Lock multiple acquire safety issue (GH-5466)
https://github.com/python/cpython/
Yury Selivanov <yseliva...@gmail.com> added the comment:
Looks like a bug. Andrew, if you have time to look at this, please feel free
to go ahead; I'm going to be unavailable till Feb 12 (so I can take a look
myself after that).
--
___
701 - 800 of 3072 matches
Mail list logo
