[issue32741] Add asyncio.TimerHandle.when() function

Yury Selivanov added the comment: The PR is LGTM. Up to Ned to allow this in 3.7. I agree that the feature is (a) trivial, (b) new, so it's safe to go in 3.7. -- ___ Python tracker <https://bugs.python.org/is

[issue32741] Add asyncio.TimerHandle.when() function

Yury Selivanov added the comment: > Let's get it into master for 3.8 first and then we'll have something to > discuss. The PR has a "versionadded" tag. If you plan to allow this, Andrew can commit it set to 3.7... --

[issue31356] Add context manager to temporarily disable GC

Yury Selivanov added the comment: Raymond, do you need help with reverts? -- ___ Python tracker <https://bugs.python.org/issue31356> ___ ___ Python-bugs-list m

[issue32741] Add asyncio.TimerHandle.when() function

Yury Selivanov added the comment: Andrew, I'm indifferent about this feature. It's entirely up to you if you want to merge it in 3.7. I already used up my allowance for post-beta1 feature merges. -- ___ Python tracker <https://bu

[issue32743] Typo in hamt.c comments

Yury Selivanov added the comment: Yeah, please submit a PR -- ___ Python tracker <https://bugs.python.org/issue32743> ___ ___ Python-bugs-list mailing list Unsub

[issue32436] Implement PEP 567

Change by Yury Selivanov : -- pull_requests: +5314 ___ Python tracker <https://bugs.python.org/issue32436> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32436] Implement PEP 567

Yury Selivanov added the comment: New changeset 55e0839f2672e029c2b96514028c77c31ffbe41f by Yury Selivanov in branch 'master': bpo-32436: Fix compiler warning (#5483) https://github.com/python/cpython/commit/55e0839f2672e029c2b96514028c77

[issue32436] Implement PEP 567

Yury Selivanov added the comment: New changeset 78767786a87b00925506c32b3b55cf65b56ef3d7 by Yury Selivanov (Miss Islington (bot)) in branch '3.7': bpo-32436: Fix compiler warning (GH-5483) (GH-5486) https://github.com/python/cpython/commit/78767786a87b00925506c32b3b55cf

[issue31356] Add context manager to temporarily disable GC

Change by Yury Selivanov : -- pull_requests: +5328 ___ Python tracker <https://bugs.python.org/issue31356> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31356] Add context manager to temporarily disable GC

Yury Selivanov added the comment: Since I'm going to be unavailable for the next 10 days, and I don't want this to be accidentally forgotten, I'll do the revert myself. Opened a PR for that. -- assignee: rhettinger -> ___ Pyth

[issue31356] Add context manager to temporarily disable GC

Yury Selivanov added the comment: New changeset 383b32fe108ea627699cc9c644fba5f8bae95d73 by Yury Selivanov in branch 'master': Revert "bpo-31356: Add context manager to temporarily disable GC GH-5495 https://github.com/python/cpython/commit/383b32fe108ea627699cc9c64

[issue31356] Add context manager to temporarily disable GC

Yury Selivanov added the comment: New changeset 29fd9eae432a54c963262e895b46f081f238539a by Yury Selivanov (Miss Islington (bot)) in branch '3.7': Revert "bpo-31356: Add context manager to temporarily disable GC GH-5495 (#5496) https://github.com/python

[issue31356] Add context manager to temporarily disable GC

Change by Yury Selivanov : -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue32748] Improve _asyncio.TaskStepMethWrapper and TaskWakeupMethWrapper reprs

Yury Selivanov added the comment: I think I've fixed that. Can you give me a script to repro? -- ___ Python tracker <https://bugs.python.org/issue32748> ___ ___

[issue31356] Add context manager to temporarily disable GC

Yury Selivanov added the comment: > The idea which this issue represents is not rejected. It is a good one, we > found a need for it during the dev sprint last September. Well, not everybody thinks it is a good one. I, for instance, don't think it's a good idea, so it is

[issue32751] wait_for(future, ...) should wait for the future (even if a timeout occurs)

Yury Selivanov 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). -- ___ Python tracker &

[issue32734] Asyncio Lock safety issue (unlimited acquire)

Yury Selivanov 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/commit/2f79c014931cbb23b08a7d16c534a3

[issue32734] Asyncio Lock safety issue (unlimited acquire)

Yury Selivanov 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/cpyt

[issue32734] Asyncio Lock safety issue (unlimited acquire)

Yury Selivanov 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/cpyt

[issue32734] Asyncio Lock safety issue (unlimited acquire)

Yury Selivanov 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 ___ Python tracker <https://bugs.python.or

[issue32753] ssl.SSLError exceptions in test_poplib

Change by Yury Selivanov : -- nosy: -yselivanov ___ Python tracker <https://bugs.python.org/issue32753> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32754] feature request: asyncio.gather/wait cancel children on first exception

Yury Selivanov 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 some very WIP code that

[issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong.

Yury Selivanov 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/cpyt

[issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong.

Yury Selivanov 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/cpyt

[issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong.

Change by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue32841] Asyncio.Condition prevents cancellation

Yury Selivanov 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 submit

[issue32841] Asyncio.Condition prevents cancellation

Change by Yury Selivanov : Removed file: https://bugs.python.org/file47441/le_meme.jpg ___ Python tracker <https://bugs.python.org/issue32841> ___ ___ Python-bugs-list m

[issue32436] Implement PEP 567

Change by Yury Selivanov : -- pull_requests: +5481 ___ Python tracker <https://bugs.python.org/issue32436> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32436] Implement PEP 567

Yury Selivanov 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/bd093355a6aaf2f4ca3ed153e195da

[issue32436] Implement PEP 567

Yury Selivanov 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 <https://bugs.pyth

[issue32856] Optimize the `for y in [x]` idiom in comprehensions

Yury Selivanov 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 extra visib

[issue32604] Expose the subinterpreters C-API in Python for testing use.

Yury Selivanov 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.52 [1/1] test_multiprocessing_fork

[issue32604] Expose the subinterpreters C-API in Python for testing use.

Yury Selivanov 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 tracker <https://bugs.py

[issue33009] Assertion failure in inspect.signature on unbound partialmethods

Change by Yury Selivanov : -- keywords: +patch pull_requests: +5769 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue33009] Assertion failure in inspect.signature on unbound partialmethods

Yury Selivanov added the comment: Yeah, that assertion needs to be tweaked a little bit. Created a PR. -- ___ Python tracker <https://bugs.python.org/issue33

[issue32992] unittest: Automatically run coroutines in a loop

Yury Selivanov 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 ___ Python tracker <ht

[issue33009] Assertion failure in inspect.signature on unbound partialmethods

Yury Selivanov 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/commit/8a387219bdfb6ee34928d6168ac42c

[issue32992] unittest: Automatically run coroutines in a loop

Yury Selivanov 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 coroutine support _

[issue32972] unittest.TestCase coroutine support

Yury Selivanov 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 executed by asyncio. And you s

[issue32972] unittest.TestCase coroutine support

Yury Selivanov 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 <https://bugs.python.org/i

[issue33009] Assertion failure in inspect.signature on unbound partialmethods

Change by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue32972] unittest.TestCase coroutine support

Yury Selivanov 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' namespace f

[issue32972] unittest.TestCase coroutine support

Yury Selivanov 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 that: https://g

[issue32972] unittest.TestCase coroutine support

Yury Selivanov 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 incompatible change. Moreo

[issue32972] unittest.TestCase coroutine support

Yury Selivanov 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 needs to work correct

[issue32517] test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

Yury Selivanov 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/commit/12f74d8608c15cacd9d5786524e2be

[issue32758] Stack overflow when parse long expression to AST

Change by Yury Selivanov : -- nosy: -yselivanov ___ Python tracker <https://bugs.python.org/issue32758> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33041] Issues with "async for"

Yury Selivanov 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 will break any "async

[issue32972] unittest.TestCase coroutine support

Yury Selivanov 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 there's plent

[issue32972] unittest.TestCase coroutine support

Yury Selivanov 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. Maybe we could add a helper

[issue33115] Asyncio loop blocks with a lot of parallel tasks

Yury Selivanov 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 framework. -- ___

[issue33115] Asyncio loop blocks with a lot of parallel tasks

Yury Selivanov added the comment: The "blocking" you observe is caused by Python GC. If I add "import gc; gc.disable()" the warnings disappear. -- ___ Python tracker <https://bug

[issue33118] No clean way to get notified when a Transport's write buffer empties out

Yury Selivanov 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 the way?

[issue33118] No clean way to get notified when a Transport's write buffer empties out

Yury Selivanov 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 buffers. -- ___ P

[issue33118] No clean way to get notified when a Transport's write buffer empties out

Yury Selivanov 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/event loops that are

[issue33115] Asyncio loop blocks with a lot of parallel tasks

Yury Selivanov 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 and PyPy at this moment. &g

[issue33118] No clean way to get notified when a Transport's write buffer empties out

Yury Selivanov 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 are sch

[issue33179] Investigate using a context variable for zero-arg super initialisation

Yury Selivanov 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 to run in

[issue33179] Investigate using a context variable for zero-arg super initialisation

Yury Selivanov 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 whole > thing. Hum, yeah

[issue29922] error message when __aexit__ is not async

Yury Selivanov 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 <https://bugs.python.org/issu

[issue29922] error message when __aexit__ is not async

Yury Selivanov added the comment: 3.5 is in security fixes only, so don't bother. -- ___ Python tracker <https://bugs.python.org/issue29922> ___ ___ Pytho

[issue33221] Add stats for asyncio task usage.

Yury Selivanov 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. The plan is to prototype it in uvloop fi

[issue31033] Add argument to .cancel() of Task and Future

Yury Selivanov 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 cancelled. Why don&

[issue33265] contextlib.ExitStack abuses __self__

Yury Selivanov added the comment: Yep, I think this is a good fix! -- ___ Python tracker <https://bugs.python.org/issue33265> ___ ___ Python-bugs-list mailin

[issue33363] async for statement is not a syntax error in sync context

Yury Selivanov 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 <https://bugs.python.org/issu

[issue33366] `contextvars` documentation incorrectly refers to "non-local state".

Yury Selivanov added the comment: I like what you propose. Can you submit a PR? :) -- ___ Python tracker <https://bugs.python.org/issue33366> ___ ___ Python-bug

[issue33363] async for statement is not a syntax error in sync context

Yury Selivanov 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/cpyt

[issue33363] async for statement is not a syntax error in sync context

Yury Selivanov added the comment: Thanks so much! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue33363] async for statement is not a syntax error in sync context

Yury Selivanov 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/python/cpyt

[issue33366] `contextvars` documentation incorrectly refers to "non-local state".

Yury Selivanov added the comment: Thank you, Tom! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue33346] Syntax error with async generator inside dictionary comprehension

Yury Selivanov 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 implicit asynchronous compre

[issue33346] Syntax error with async generator inside dictionary comprehension

Yury Selivanov 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 synchronous contexts, e

[issue31556] asyncio.wait_for can cancel futures faster with timeout==0

Change by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior ___ Python tracker <https://bugs.python

[issue31556] asyncio.wait_for can cancel futures faster with timeout==0

Yury Selivanov added the comment: Note, that this will not be backported to 3.6, as it behaves in a slightly incompatible way. I consider this patch as an enhancement that makes 'asyncio.wait_for' semantics easier to reason about and more

[issue30406] async and await should be keywords in 3.7

Yury Selivanov added the comment: New changeset ac317700ce7439e38a8b420218d9a5035bba92ed by Yury Selivanov (Jelle Zijlstra) in branch 'master': bpo-30406: Make async and await proper keywords (#1669) https://github.com/python/cpython/commit/ac317700ce7439e38a8b420218d9a5

[issue30406] async and await should be keywords in 3.7

Yury Selivanov added the comment: Thanks a lot, Jelle! -- resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior ___ Python tracker <https://bugs.python

[issue31708] Allow use of asynchronous generator expressions in synchronous functions

Change by Yury Selivanov : -- assignee: yselivanov components: Interpreter Core nosy: yselivanov priority: normal severity: normal status: open title: Allow use of asynchronous generator expressions in synchronous functions type: behavior versions: Python 3.7

[issue31709] Drop support for asynchronous __aiter__

New submission from Yury Selivanov : As discussed in issue 27243, we want to drop support of asynchronous __aiter__ in Python 3.7. Together with issue 30406, this will enable us to add support for using asynchronous generator expressions in synchronous functions (issue 31708

[issue31708] Allow use of asynchronous generator expressions in synchronous functions

New submission from Yury Selivanov : Prior to Python 3.7 we couldn't enable use of asynchronous generator expressions in synchronous functions: async arange(n): for i in range(n): yield i def make_arange(n): return (i async for i in ara

[issue31709] Drop support for asynchronous __aiter__

Change by Yury Selivanov : -- keywords: +patch pull_requests: +3874 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31709> ___ ___ Py

[issue31709] Drop support for asynchronous __aiter__

Yury Selivanov added the comment: New changeset faa135acbfcd55f79fb97f7525c8aa6f5a5b6a22 by Yury Selivanov in branch 'master': bpo-31709: Drop support for asynchronous __aiter__. (#3903) https://github.com/python/cpython/commit/faa135acbfcd55f79fb97f7525c8aa

[issue31709] Drop support for asynchronous __aiter__

Change by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue31708] Allow use of asynchronous generator expressions in synchronous functions

Change by Yury Selivanov : -- keywords: +patch pull_requests: +3876 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31708> ___ ___ Py

[issue31709] Drop support for asynchronous __aiter__

Change by Yury Selivanov : -- pull_requests: +3877 ___ Python tracker <https://bugs.python.org/issue31709> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31708] Allow use of asynchronous generator expressions in synchronous functions

Yury Selivanov added the comment: (this is per PEP 530: https://www.python.org/dev/peps/pep-0530/#asynchronous-comprehensions) -- ___ Python tracker <https://bugs.python.org/issue31

[issue31708] Allow use of asynchronous generator expressions in synchronous functions

Change by Yury Selivanov : -- nosy: +ncoghlan ___ Python tracker <https://bugs.python.org/issue31708> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31708] Allow use of asynchronous generator expressions in synchronous functions

Yury Selivanov added the comment: New changeset b8ab9d3fc816f85f4d6dbef12b7414e6dc10e4dd by Yury Selivanov in branch 'master': bpo-31708: Allow async generator expressions in synchronous functions (#3905) https://github.com/python/cpython/commit/b8ab9d3fc816f85f4d6dbef12b7414

[issue31708] Allow use of asynchronous generator expressions in synchronous functions

Change by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue30457] Allow retrieve the number of waiters pending for most of the asyncio lock primitives

Yury Selivanov added the comment: Isn't this code equivalent to yours: async def get(process, key): try: return cache[key] except KeyError: if key in events: await events[key].wait() else: events[key] = asyncio.

[issue30457] Allow retrieve the number of waiters pending for most of the asyncio lock primitives

Yury Selivanov added the comment: > Not really, your code never removes the key from the events. If the cache is > cleaned all further executions will keep forever in the `wait` statement. It > is needed to create the Event again to perform at least one query to retrieve > the

[issue31778] ast.literal_eval supports non-literals in Python 3

Change by Yury Selivanov : -- nosy: -yselivanov ___ Python tracker <https://bugs.python.org/issue31778> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30457] Allow retrieve the number of waiters pending for most of the asyncio lock primitives

Yury Selivanov added the comment: > The nature of the `pending` method is to give to the developer a way to check > how many waiters are still pending. This not only helps to make this code > more explicit also other pieces of code that might need access to the length > of the wa

[issue31452] asyncio.gather does not cancel tasks if one fails

Yury Selivanov added the comment: I'm going to reject this issue as it's not backwards compatible. I'll work on adding a new TaskGroup primitive in the next couple of days that would address this problem. -- resolution: -> rejected stage: patch review ->

[issue31632] Asyncio: SSL transport does not support set_protocol()

Yury Selivanov added the comment: New changeset ea2ef5d0ca869d4550820ed53bdf56013dbb9546 by Yury Selivanov (jlacoline) in branch 'master': bpo-31632: fix set_protocol() in _SSLProtocolTransport (#3817) (#3817) https://github.com/python/cpython/commit/ea2ef5d0ca869d4550820ed53bdf56

[issue31632] Asyncio: SSL transport does not support set_protocol()

Yury Selivanov added the comment: Loïc, thank you for the contribution! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 ___ Python tracker <https://bugs.python.or

[issue31819] Add sock_recv_into to AbstractEventLoop

Yury Selivanov added the comment: I'm going to approve this unless there are any objections. -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/is

[issue31632] Asyncio: SSL transport does not support set_protocol()

Yury Selivanov added the comment: New changeset 9c23b173b823b5e6da01d85c570c7ae2ab07b38b by Yury Selivanov (Miss Islington (bot)) in branch '3.6': bpo-31632: fix set_protocol() in _SSLProtocolTransport (GH-3817) (GH-3817) (#4052) https://github.com/python/cpyt

[issue31819] Add sock_recv_into to AbstractEventLoop

Yury Selivanov added the comment: New changeset 525f40d231aba2c004619fc7a5207171ed65b0cb by Yury Selivanov (Antoine Pitrou) in branch 'master': bpo-31819: Add AbstractEventLoop.sock_recv_into() (#4051) https://github.com/python/cpython/commit/525f40d231aba2c004619fc7a52071

[issue31819] Add sock_recv_into to AbstractEventLoop

Yury Selivanov added the comment: Merged. Thank you, Antoine! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue31811] async and await missing from keyword list in lexical analysis doc

Yury Selivanov added the comment: They are covered here: https://github.com/python/cpython/blob/4a2d00cb4525fcb3209f04531472ba6a359ed418/Doc/reference/compound_stmts.rst#coroutines -- resolution: -> not a bug stage: -> resolved status: open -&g

<    3   4   5   6   7   8   9   10   11   12   >