[issue34971] add support for tls/ssl sessions in asyncio

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/issue34

[issue35826] Typo in example for async with statement with condition

Yury Selivanov added the comment: Please submit a PR! -- components: +asyncio -Documentation keywords: +easy nosy: +asvetlov, yselivanov ___ Python tracker <https://bugs.python.org/issue35

[issue35749] Rewrite asyncio signal handler

Change by Yury Selivanov : -- stage: resolved -> needs patch ___ Python tracker <https://bugs.python.org/issue35749> ___ ___ Python-bugs-list mailing list Un

[issue35749] Rewrite asyncio signal handler

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 manifests

[issue35751] traceback.clear_frames manages to deadlock a background task

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://bugs.python.

[issue35527] Make fields selectively immutable in dataclasses

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.org/issue35

[issue35465] [asyncio] Document loop.add_signal_handler

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/cpython/commit

[issue35465] [asyncio] Document loop.add_signal_handler

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

[issue35465] [asyncio] Document loop.add_signal_handler

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/cpython/commit

[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers

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/issue29

[issue32810] Expose ags_gen and agt_gen in asynchronous generators

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.org/issue32

[issue35456] asyncio.Task.set_result() and set_exception() missing docstrings (and Liskov sub. principle)

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 right now

[issue21314] Document '/' in signatures

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

[issue35269] A possible segfault involving a newly-created coroutine

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

[issue23554] EchoServerClientProtocol class should be called EchoServerProtocol

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

[issue23554] EchoServerClientProtocol class should be called EchoServerProtocol

Yury Selivanov added the comment: New changeset 43a5bd7b458f0ad2d62b00b033d025689d48d591 by Yury Selivanov (Braden Groom) in branch 'master': bpo-23554: Change echo server example class name from EchoServerClientProtocol to EchoServerProtocol (GH-9859) https://github.com/python/cpython

[issue34993] asyncio.streams.FlowControlMixin should be part of the API

Yury Selivanov added the comment: asvetlov: need to handle this usecase with the new API; -1 on exposing FlowControlMixin though. -- ___ Python tracker <https://bugs.python.org/issue34

[issue34975] start_tls() difficult when using asyncio.start_server()

Yury Selivanov added the comment: One thing: I'm -1 on adding starttls to current stream api; let's add it only to the new one (same for sendfile) -- ___ Python tracker <https://bugs.python.org/issue34

[issue34968] loop.call_soon_threadsafe should be documented to be re-entrant-safe too

Yury Selivanov added the comment: > AFAICT the stdlib's implementation of call_soon_threadsafe is already > reentrant-safe What would make it not reentrant-safe? We'll need to document that for the benefit of asyncio and third-party maint

[issue34970] Protect tasks weak set manipulation in asyncio.all_tasks()

Yury Selivanov added the comment: >> we could consider risking cherry-picking it to 3.7.1 final. Sound OK? > Let's wait for Yuri opinion. I agree it's a pretty serious bug; basically a time bomb that can crash a perfectly fine asyncio application. The PR itself seems to be safe t

[issue32052] Provide access to buffer of asyncio.StreamReader

Yury Selivanov added the comment: So we have BufferedProtocol in 3.7; now we need to re-implement asyncio streams on top of it. But even after doing that I'm not that sure we want to expose the low-level buffer. -- stage: needs patch

[issue26467] Add async magic method support to unittest.mock.Mock

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

[issue34769] _asyncgen_finalizer_hook running in wrong thread

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

[issue34769] _asyncgen_finalizer_hook running in wrong thread

Yury Selivanov added the comment: I'll close this issue now. If you find another bug in how asyncio handles async generators please open a new one. Thanks! -- ___ Python tracker <https://bugs.python.org/issue34

[issue34769] _asyncgen_finalizer_hook running in wrong thread

Yury Selivanov added the comment: New changeset a14dda5df62369d01db6c7519e73aae71d0e7cfe by Yury Selivanov (twisteroid ambassador) in branch '3.6': [3.6] bpo-34769: Thread safety for _asyncgen_finalizer_hook(). (GH-9716) (GH-9792) https://github.com/python/cpython/commit

[issue34769] _asyncgen_finalizer_hook running in wrong thread

Yury Selivanov added the comment: New changeset c880ffe7d2ce2fedb1831918c8a36e3623e0fb76 by Yury Selivanov (twisteroid ambassador) in branch 'master': bpo-34769: Thread safety for _asyncgen_finalizer_hook(). (GH-9716) https://github.com/python/cpython/commit

[issue34872] investigate task/future cancellation in asynciomodule.c

Yury Selivanov added the comment: Closing it now, Ned, thanks! I assume it will make it into 3.7.1rc2, right? -- priority: release blocker -> normal resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Py

[issue34795] loop.sock_recv failure because of delayed callback handling

Yury Selivanov added the comment: yes -- ___ Python tracker <https://bugs.python.org/issue34795> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34831] Asyncio Tutorial

Yury Selivanov added the comment: > Yury, based on the file paths, you appear to be running a MacPorts python3.7. > Like many other third-party distributors (but unlike the python.org > installers), MacPorts separates Tkinter support into a separately-installable > com

[issue34871] test_site fails if run after test_inspect

Yury Selivanov added the comment: Thank you Inada-san for taking care of this. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue34871] test_site fails if run after test_inspect

Yury Selivanov added the comment: New changeset 476c294f260ebe1b44157a168c3dfa4a43724ce3 by Yury Selivanov (Miss Islington (bot)) in branch '3.7': bpo-34871: inspect: Don't pollute sys.modules (GH-9696) (#9701) https://github.com/python/cpython/commit/476c294f260ebe1b44157a168c3dfa4a43724ce3

[issue34871] test_site fails if run after test_inspect

Yury Selivanov added the comment: New changeset 70a083bc46aea84e3b3ffca2c10c295917a98fec by Yury Selivanov (Miss Islington (bot)) in branch '3.6': bpo-34871: inspect: Don't pollute sys.modules (GH-9696) (GH-9702) https://github.com/python/cpython/commit

[issue34776] Postponed annotations break inspection of dataclasses

Yury Selivanov added the comment: > Please note that postponed annotations only reveal a problem that we already > had if anybody used a string forward reference: Yeah, makes sense. It's cool that the PR fixes string forward references as

[issue34890] Support functools.partial in inspect.is*function() checks

Yury Selivanov added the comment: Feel free to work on the PR. If we want to push this to 3.8 we should do that now and have enough time for it to be tested. -- ___ Python tracker <https://bugs.python.org/issue34

[issue34890] Support functools.partial in inspect.is*function() checks

Yury Selivanov added the comment: I think the fact that `inspect.isfunction` recognizes partials is a very strong argument to enable inspect.iscoroutinefunction to do so as well. This is a backwards incompatible change though, strictly speaking

[issue34888] Python3.8 optimizes away a "while" line

Yury Selivanov added the comment: > I assume there is some place that notices that the while condition is a > constant, and therefore doesn't need to be explicitly evaluated? To answer your question: yes, and it's unrelated to both peephole optimizer and to the above mentioned

[issue2506] Add mechanism to disable optimizations

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

[issue34888] Python3.8 optimizes away a "while" line

Yury Selivanov added the comment: > I assume there is some place that notices that the while condition is a > constant, and therefore doesn't need to be explicitly evaluated? Ah, I see what you're asking about. I'll need to double

[issue34888] Python3.8 optimizes away a "while" line

Yury Selivanov added the comment: It's more complicated than that: there's no more SETUP_LOOP opcode anymore. The ceval and compiler parts responsible for evaluating and compiling loops were rewritten. FWIW the goal was more about simplifying the needlessly complicated implementation

[issue34888] Python3.8 optimizes away a "while" line

Yury Selivanov added the comment: While I agree with you that we need a flag to disable optimizations, this particular change isn't related to AST or peephole optimizers. See the bpo-17611 for more details (or https://github.com/python/cpython/commit/520b7ae27e39d1c77ea74ccd1b184d7cb43f9dcb

[issue2506] Add mechanism to disable optimizations

Yury Selivanov added the comment: > I would suggest -X noopt and use "noopt" in .pyc filenames. That's what I > proposed in my PEP 511. Sounds good to me. -- ___ Python tracker <https://bugs.p

[issue2506] Add mechanism to disable optimizations

Yury Selivanov added the comment: Having properly working coverage tooling is simply invaluable to pretty much every serious Python user. I support Ned's idea of adding an option to disable peephole optimizer (and similar other optimization passes). Why is this even debated

[issue34822] Simplify AST for slices

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

[issue34872] investigate task/future cancellation in asynciomodule.c

Yury Selivanov added the comment: > What's your assessment of the risk of option 2? Let's not rush it in without testing, for sure. Having 3.7.1rc2 would be great, but really up to you. -- ___ Python tracker <https://bugs.python.org/issu

[issue34872] investigate task/future cancellation in asynciomodule.c

Yury Selivanov added the comment: Ned, elevating this to "release blocker", see https://bugs.python.org/msg326928 Feel free to close this issue. -- priority: normal -> release blocker ___ Python tracker <https://bugs.pytho

[issue34014] loop.run_in_executor should propagate current contextvars

Change by Yury Selivanov : -- status: pending -> open versions: -Python 3.7 ___ Python tracker <https://bugs.python.org/issue34014> ___ ___ Python-bugs-lis

[issue34014] loop.run_in_executor should propagate current contextvars

Yury Selivanov added the comment: > It is a new feature for Python 3.8 anyway, no need to rush Yep, I agree. Let's see if we end up having a new nice high-level API in 3.8; if not we go for (3). -- resolution: -> postponed status: open -> pending type: ->

[issue34831] Asyncio Tutorial

Yury Selivanov added the comment: > I too have bashed my head for many hours over the years trying to get Tkinter > to work on Mac, but a lot of work has gone into this recently and the newer > (release) Python's have bundled Tk 8.6: > https://www.python.org/download/mac/tcltk/ (

[issue34014] loop.run_in_executor should propagate current contextvars

Yury Selivanov added the comment: [Andrew] > I vote on not changing `run_in_executor` behavior if we cannot make it work > with `ProcessPoolExecutor`. > If a new API will solve the problem -- that's fine. Until it landed the explicit context propagation is the satisfactory soluti

[issue34872] investigate task/future cancellation in asynciomodule.c

Yury Selivanov added the comment: New changeset 0c797a6aca1c293e530e18c5e9fa02c670a9a4ed by Yury Selivanov (Elvis Pranskevichus) in branch 'master': bpo-34872: Fix self-cancellation in C implementation of asyncio.Task (GH-9679) https://github.com/python/cpython/commit

[issue34885] asyncio documention has lost its paragraph about cancellation

Yury Selivanov added the comment: The cancellation is now discussed in this section:https://docs.python.org/3/library/asyncio-task.html (search for "cancel") and in particular in the Task subsection. Is there any important detail that was covered in the old documentation and i

[issue34872] investigate task/future cancellation in asynciomodule.c

Yury Selivanov added the comment: Ned, will we have 3.7.1rc2? If so, would it be possible to include the fix for this one? -- nosy: +ned.deily ___ Python tracker <https://bugs.python.org/issue34

[issue34872] investigate task/future cancellation in asynciomodule.c

Yury Selivanov added the comment: Elvis, please take a look at this. -- ___ Python tracker <https://bugs.python.org/issue34872> ___ ___ Python-bugs-list mailin

[issue34872] investigate task/future cancellation in asynciomodule.c

New submission from Yury Selivanov : Vladimir Matveev has discovered that C and Python implementation of asyncio.Task diverge: * asynciomodule.c: https://github.com/python/cpython/blob/9012a0fb4c4ec1afef9efb9fdb0964554ea17983/Modules/_asynciomodule.c#L2716 * tasks.py: https://github.com

[issue34728] deprecate *loop* argument for asyncio.sleep

Yury Selivanov added the comment: [victor] > Why does it not make sense to pass the loop to sleep? "it makes no sense > anymore" something changes? [andrew] `loop` argument passed to sleep should be always the same as returned from `get_running_loop()`. What Andrew

[issue34728] deprecate *loop* argument for asyncio.sleep

Yury Selivanov added the comment: New changeset 9012a0fb4c4ec1afef9efb9fdb0964554ea17983 by Yury Selivanov in branch 'master': bpo-34728: Fix asyncio tests to run under "-Werror" (GH-9661) https://github.com/python/cpython/commit/9012a0fb4c4ec1afef9efb9fdb0964

[issue34728] deprecate *loop* argument for asyncio.sleep

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

[issue34728] deprecate *loop* argument for asyncio.sleep

Yury Selivanov added the comment: > On python-committers, it has been said that 3.10 will follow Python 3.9, no? Victor, you're looking at an outdated comment on this issue. This is what's in the master branch: https://github.com/python/cpython/blob/d4c76d960b8b286b75c933780416ace9cda68

[issue34014] loop.run_in_executor should propagate current contextvars

Yury Selivanov added the comment: One problem with (3) is what will happen if someone uses "retain_context=True" and a ProcessPoolExecutor. It has to fail in a graceful and obvious way. -- ___ Python tracker <https://bugs.python.o

[issue34014] loop.run_in_executor should propagate current contextvars

Yury Selivanov added the comment: So we're deprecating passing non-ThreadPoolExecutor instances to loop.set_default_executor. In 3.9 that will trigger an error. For this issue we have basically the next few options: (1) Do nothing; (2) Fix "run_in_executor" to start copying a

[issue34430] Symmetrical chaining futures in asyncio.future.wrap_future

Yury Selivanov added the comment: The PR needs a very careful review, but in general I'm OK with the idea. I'm also curious why do you want to fix wrap_future -- how are you using it? -- ___ Python tracker <https://bugs.python.org/issue34

[issue34769] _asyncgen_finalizer_hook running in wrong thread

Yury Selivanov added the comment: Rereading your first message: > When testing my happy eyeballs library, I occasionally run into issues with > async generators seemingly not finalizing. After setting > loop.set_debug(True), I have been seeing log entries like these: The bug we a

[issue34769] _asyncgen_finalizer_hook running in wrong thread

Yury Selivanov added the comment: Wow. Thanks so much for figuring this out, I know how hard it is to debug issues like this. Now I see it clearly: _asyncgen_finalizer_hook should be using loop.call_soon_threadsafe. Interestingly, I used _write_to_self there, so I knew about the issue

[issue34831] Asyncio Tutorial

Yury Selivanov added the comment: I like this, great job! Couple of thoughts on how we should organize this: * I think we should stick to your structure and push things to docs.python.org as soon as every next section is somewhat ready. * Every big section should probably have its own

[issue34802] asyncio.iscoroutine() documentation is wrong

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

[issue34802] asyncio.iscoroutine() documentation is wrong

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

[issue34802] asyncio.iscoroutine() documentation is wrong

Yury Selivanov added the comment: New changeset 59ee5b12938efbf534f2a19300a847bf6b23a77d by Yury Selivanov in branch 'master': bpo-34802: Fix asyncio.iscoroutine() docs (GH-9611) https://github.com/python/cpython/commit/59ee5b12938efbf534f2a19300a847bf6b23a77d

[issue34802] asyncio.iscoroutine() documentation is wrong

Yury Selivanov added the comment: I'll make a simple fix for the asyncio.coroutine decorator docs. > I would suggest below for #coroutines : >> Coroutines declared with async/await syntax is the preferred way of writing >> asyncio applications but asyncio also supports l

[issue34802] asyncio.iscoroutine() documentation is wrong

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

[issue34762] Change contextvars C API to use PyObject

Yury Selivanov added the comment: Thank you Serhiy, for re-opening this! I've pushed fixes to 3.7 and master branches. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue34762] Change contextvars C API to use PyObject

Yury Selivanov added the comment: New changeset 24cb7de15d3a5979425b281ab4f600f7c2b401f2 by Yury Selivanov in branch '3.7': [3.7] bpo-34762: Update PyContext* refs to PyObject* in asyncio and decimal (GH-9610) https://github.com/python/cpython/commit/24cb7de15d3a5979425b281ab4f600f7c2b401f2

[issue34762] Change contextvars C API to use PyObject

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

[issue34762] Change contextvars C API to use PyObject

Yury Selivanov added the comment: New changeset 994269ccee5574f03cda6b018399347fc52bf330 by Yury Selivanov in branch 'master': bpo-34762: Update PyContext* to PyObject* in asyncio and decimal (GH-9609) https://github.com/python/cpython/commit/994269ccee5574f03cda6b018399347fc52bf330

[issue34762] Change contextvars C API to use PyObject

Change by Yury Selivanov : -- pull_requests: +9007 stage: resolved -> patch review ___ Python tracker <https://bugs.python.org/issue34762> ___ ___ Python-

[issue34762] Change contextvars C API to use PyObject

Yury Selivanov added the comment: Right, I'll make a PR. -- ___ Python tracker <https://bugs.python.org/issue34762> ___ ___ Python-bugs-list mailing list Unsub

[issue34824] _ssl.c: Possible null pointer dereference

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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

Yury Selivanov added the comment: PendingDeprecationWarning -- ___ Python tracker <https://bugs.python.org/issue34790> ___ ___ Python-bugs-list mailin

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

Yury Selivanov added the comment: Actually, since Andrew also agrees that we need to deprecate passing coroutines to wait(), I'll keep this issue open until we add an actual DeprecationWarning in 3.8. -- resolution: fixed -> stage: resolved -> status: closed -

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

Yury Selivanov added the comment: New changeset 996859a90df51f84eab47351702cb59c6db4428a by Yury Selivanov in branch 'master': bpo-34790: [docs] Passing coroutines to asyncio.wait() can be confusing. (GH-9543) https://github.com/python/cpython/commit/996859a90df51f84eab47351702cb59c6db4428a

[issue34687] asyncio: is it time to make ProactorEventLoop as the default event loop?

Yury Selivanov added the comment: New changeset 6ea29c5e90dde6c240bd8e0815614b52ac307ea1 by Yury Selivanov (Victor Stinner) in branch 'master': bpo-34687: Make asynico use ProactorEventLoop by default (GH-9538) https://github.com/python/cpython/commit/6ea29c5e90dde6c240bd8e0815614b52ac307ea1

[issue34776] Postponed annotations break inspection of dataclasses

Yury Selivanov added the comment: NP, Eric, take your time. I agree that the PR isn't simple and needs a very careful review. -- ___ Python tracker <https://bugs.python.org/issue34

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Yury Selivanov added the comment: See also https://bugs.python.org/issue34795 -- nosy: +asvetlov versions: +Python 3.8 -Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue30

[issue34795] loop.sock_recv failure because of delayed callback handling

Yury Selivanov added the comment: Can you reproduce this with uvloop? Andrew: I think we need to "lock" sockets from closing in sock_recv and friends the same way we do it in uvloop. -- ___ Python tracker <https://bugs.python.o

[issue34793] Remove support for "with (await asyncio.lock):"

New submission from Yury Selivanov : Never mind, we do this already. The question is then should we just remove the support for this syntax entirely in 3.8, or we should wait until 3.9? -- title: Raise DeprecationWarning for "with (await lock):" -> Remove support for

[issue34793] Raise DeprecationWarning for "with (await lock):"

Change by Yury Selivanov : -- components: asyncio nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Raise DeprecationWarning for "with (await lock):" versions: Python 3.8 ___ Python tracker <https://bu

[issue32528] Change base class for futures.CancelledError

Yury Selivanov added the comment: > Closing this issue as I, personally, don't see this happening and there's no > point in keeping it open. Actually, Andrew and I changed our opinion on this, so I'm re-opening the issue. After visiting three conferences this summer and talking to a

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

Yury Selivanov added the comment: > 4.0 is too far. Why not disallow them in 3.10? What's the current plan? I thought it's going to be 3.8, 3.9, 4.0. Is there a PEP detailing this? -- ___ Python tracker <https://bugs.python.org/issu

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

New submission from Yury Selivanov : asyncio.wait() accepts coroutines, wraps them into Tasks, and later returns those implicitly created Tasks in (done, pending) sets. This is very confusing to new asyncio users and it's almost impossible to figure out what is going on. See the first PR

[issue34788] ipaddress module fails on rfc4007 scoped IPv6 addresses

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

[issue34776] Postponed annotations break inspection of dataclasses

Yury Selivanov added the comment: And FWIF I don't think we need to use lambdas for annotations to solve issues like this one. -- ___ Python tracker <https://bugs.python.org/issue34

[issue34776] Postponed annotations break inspection of dataclasses

Yury Selivanov added the comment: > See this for Yury's self-described "hack-ish fix we can use" until we do > something better: Actually, I think I found a better solution that doesn't require any changes to anything besides dataclasses. Currently, dataclasses uses '

[issue34776] Postponed annotations break inspection of dataclasses

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

[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads

Yury Selivanov added the comment: > Yury, Andrew: Do you know if the executor doesn't wait on purpose? Would it > be possible to change that in Python 3.8? Maybe. At least we need to add a "timeout" argument to asyncio.run() to let it wait for executor jobs. I'm also think

[issue33649] asyncio docs overhaul

Yury Selivanov added the comment: New changeset e45662c28bfc84aa3674463a2995e45da4d63793 by Yury Selivanov (Miss Islington (bot)) in branch '3.7': bpo-33649: Fix gather() docs; fix title; few other nits. (GH-9475) (GH-9481) https://github.com/python/cpython/commit

[issue33649] asyncio docs overhaul

Yury Selivanov added the comment: New changeset db1a80e97aa7217c561fb3627f70be1882de9534 by Yury Selivanov in branch 'master': bpo-33649: Fix gather() docs; fix title; few other nits. (GH-9475) https://github.com/python/cpython/commit/db1a80e97aa7217c561fb3627f70be1882de9534

[issue34762] Change contextvars C API to use PyObject

Yury Selivanov added the comment: Fixed in master and 3.7. Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement ___ Python tracker <https://bugs.python

[issue34762] Change contextvars C API to use PyObject

Yury Selivanov added the comment: PEP update: https://github.com/python/peps/commit/977a94d1a79b71336568119eb689b277d2ffec80 -- ___ Python tracker <https://bugs.python.org/issue34

[issue34762] Change contextvars C API to use PyObject

Yury Selivanov added the comment: New changeset 2ec872b31e25cee1f983fe07991fb53f3fd1cbac by Yury Selivanov in branch 'master': bpo-34762: Fix contextvars C API to use PyObject* pointer types. (GH-9473) https://github.com/python/cpython/commit/2ec872b31e25cee1f983fe07991fb53f3fd1cbac

<    1   2   3   4   5   6   7   8   9   10   >