[issue43794] OpenSSL 3.0.0: Handle UNEXPECTED_EOF_WHILE_READING / wrap SSL_OP_IGNORE_UNEXPECTED_EOF

Alex Grönholm added the comment: OpenSSL 1.1.1 also handled EOFs strictly, but this behavior was generally suppressed in the ssl module through the default setting of suppress_ragged_eofs=True (thus enabling truncation attacks by default). The PR changes the behavior of existing applications

[issue40059] Provide a toml module in the standard library

Change by Alex Grönholm : -- nosy: +alex.gronholm ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46313] SSLObject does not raise SSLEOFError on OpenSSL 3

New submission from Alex Grönholm : PR #25309 (https://github.com/python/cpython/pull/25309) changed OpenSSL behavior so that it ignores unexpected EOFs by default. This was detected by the test suites of both trio and AnyIO when running on OpenSSL 3. We worked around the problem by

[issue46313] SSLObject does not raise SSLEOFError on OpenSSL 3

Alex Grönholm added the comment: This is a security issue because it exposes users to TLS truncation attacks that weren't possible before because such attempts would raise SSLEOFError. -- ___ Python tracker <https://bugs.python.org/is

[issue46313] SSLObject does not raise SSLEOFError on OpenSSL 3

Alex Grönholm added the comment: I hope the Fedora maintainers/packagers know this because on Rawhide, Python is being compiled against OpenSSL 3 (which is how we discovered the problem). F36 is due out in a little over 3 months. -- ___ Python

[issue46313] SSLObject does not raise SSLEOFError on OpenSSL 3

Alex Grönholm added the comment: Good to see that this is being handled. I could try to write a patch to do what I suggested above, if you're willing to review it. -- ___ Python tracker <https://bugs.python.org/is

[issue46313] SSLObject does not raise SSLEOFError on OpenSSL 3

Alex Grönholm added the comment: I just noticed that Ubuntu 22.04 LTS also uses OpenSSL 3 with their Python builds. I hope somebody has told them too about the state of affairs. -- ___ Python tracker <https://bugs.python.org/issue46

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: A brief explanation of cancel scopes for the uninitiated: A cancel scope can enclose just a part of a coroutine function, or an entire group of tasks. They can be nested within each other (by using them as context managers), and marked as shielded from

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: I'm not trying to argue that asyncio should be changed to have level cancellation or even cancel scopes as built-in (at this point), but expanding the low level API to make implementing these features possible in third party libraries without the aw

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: Thanks, I will take a look at .uncancel() and .cancelling(). I saw that work happening in my email feed but couldn't figure out right away how it helped, but I will definitely look into the new TaskGroup code to see how it's used there and will g

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: I just tried to write a snippet to demonstrate the issue in TaskGroup, but that doesn't seem possible since TaskGroup never swallows a CancelledError. It always raises/propagates _some_ exception out of __aexit__() unless of course all the child tasks r

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: @Guido you asked for the AnyIO implementation of Happy Eyeballs; here it is: https://github.com/agronholm/anyio/blob/ac3e7c619913bd0ddf9c36b6e633b278d07405b7/src/anyio/_core/_sockets.py#L85 (I didn't paste the actual code here because it's wa

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: I am also uncomfortable using the cancel message to deliver the token/nonce/whatever. If TaskGroup.cancel() is implemented, would it also deliver a cancellation in the parent task like trio and AnyIO do? It should IMHO, because otherwise if the task group is

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: I propose the following, backwards compatible solution: Add a new keyword argument to Task.cancel(): "scope: object = None". The behavior would be as follows: the scope is saved, and included in the raised CancelledError. If Task.cancel() is called

[issue46805] Add low level UDP socket functions to asyncio

New submission from Alex Grönholm : The asyncio module currently has a number of low-level functions for working asynchronously with raw socket objects. Such functions for working with UDP sockets are, however, notably absent, and there is no workaround for this. You can of course use

[issue46805] Add low level UDP socket functions to asyncio

Alex Grönholm added the comment: One question: should I add the "flags" argument to the new functions? For some reason it's missing from the existing functions, so maybe I should add that in a separate PR? -- ___ Python

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: Can I also get comments on my proposal for the "scope" parameter? Is there a use case it would not solve? -- ___ Python tracker <https://bugs.python.o

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: > Alex, the 'scope' argument can be added if it is really required. > I'm not sure if the nonce is unavoidable still. What other generic solution is there? I've read your last few messages but didn't find an answer. There needs

[issue46805] Add low level UDP socket functions to asyncio

Change by Alex Grönholm : -- keywords: +patch pull_requests: +29583 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31455 ___ Python tracker <https://bugs.python.org/issu

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: > It looks more complicated -- the extra parameter needs to be passed around > via the task and then into the CancelledError exception. It reduces overall complexity by making uncancellation unnecessary and restoring backwards compatibility. > What

[issue46805] Add low level UDP socket functions to asyncio

Alex Grönholm added the comment: Yeah, my question was specific about the new functions, so I understood that a separate PR should add that to the all the relevant functions. I have a different problem now however: the test suite is failing in CI but not locally. It's giving me Name

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: > Propagating an ExceptionGroup where every exception can be inspected to see > if it was caused by this code or not still seems like the safe option to me > (and obviously still has the cancel count implicitly). Note that this, too, causes

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: > But, if we are using nonces on the CancelledError to keep track, then only 1 > context manager will know if it was themselves or not. This is exactly why > I'm proposing to use multiple CancelledErrors, so that every nonce is passed > to

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: > I was under the impression that ExceptionGroup was somewhat backwards > compatible, in that you could still use `except CancelledError:` and it would > catch all the errors in the group. But, maybe I'm wrong, I've not seen the > docum

[issue46771] Add some form of cancel scopes

Alex Grönholm added the comment: Yeah, I'm still interested. I'll create a new BPO when I have something. -- ___ Python tracker <https://bugs.python.o

[issue37542] UDP sendto() sends duplicate packets

Alex Grönholm added the comment: Can you reproduce this on localhost, or over Ethernet while only listening on that specific interface? If not, then likely this is just a Wireshark artifact. Failing that, you should construct a script that allows others to try to reproduce the effect

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

New submission from Alex Grönholm : Receiving a UDP datagram using DatagramProtocol on the Proactor event loop results in error_received() being called with WinError 87 (Invalid Parameter). The low-level sock_recv() works fine, but naturally loses the sender address information. The attached

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

Change by Alex Grönholm : -- components: +asyncio nosy: +yselivanov ___ Python tracker <https://bugs.python.org/issue39148> ___ ___ Python-bugs-list mailin

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

Alex Grönholm added the comment: Well, I found this: https://github.com/python/cpython/blob/3c97e1e457033bbb8bbe0b7198bd13fc794a12b0/configure.ac#L3278-L3279 Could it be that the official binaries were compiled without --enable-ipv6? -- ___ Python

[issue40213] contextlib.aclosing()

Alex Grönholm added the comment: Seconded. -- nosy: +alex.gronholm ___ Python tracker <https://bugs.python.org/issue40213> ___ ___ Python-bugs-list mailin

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

Alex Grönholm added the comment: Which PR is it? -- ___ Python tracker <https://bugs.python.org/issue39148> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

Alex Grönholm added the comment: Oh, it's https://github.com/python/cpython/pull/19121. I think it would be prudent to add a test as well to make sure this doesn't happen again. -- ___ Python tracker <https://bugs.python.o

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

Alex Grönholm added the comment: Thanks, looks good to me now! -- ___ Python tracker <https://bugs.python.org/issue39148> ___ ___ Python-bugs-list mailin

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Alex Grönholm added the comment: Has this effort gone forwards lately, or has there been any discussion elsewhere? I implemented support for "Z" in .fromisoformat() before finding this issue. Even after reading the discussion I still don't quite understand why it'

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

Alex Grönholm added the comment: The PR is still awaiting for a core developer to be reviewed. It's too bad we missed the 3.8.3 window, but perhaps this can get included in 3.9.0 at least. -- ___ Python tracker <https://bugs.python.org/is

[issue40213] contextlib.aclosing()

Alex Grönholm added the comment: They are both still useful, particularly with third party libraries. Just yesterday I found myself looking for aclosing() in contextlib, only to remember this issue. -- ___ Python tracker <https://bugs.python.

[issue40213] contextlib.aclosing()

Alex Grönholm added the comment: I think the most important use case for these is closing async generators deterministically, since they don't support the async context manager protocol. -- ___ Python tracker <https://bugs.python.org/is

[issue41317] sock_accept() does not remove server socket reader on cancellation

New submission from Alex Grönholm : Unlike with all the other sock_* functions, sock_accept() only removes the reader on the server socket when the socket becomes available for reading (ie. when there's an incoming connection). If the operation is cancelled instead, the reader is not re

[issue41317] sock_accept() does not remove server socket reader on cancellation

Alex Grönholm added the comment: This bug is the same as https://bugs.python.org/issue30064 except for sock_accept(). -- ___ Python tracker <https://bugs.python.org/issue41

[issue41332] connect_accepted_socket() missing from AbstractEventLoop

New submission from Alex Grönholm : The connect_accepted_socket() method seems to be missing from the AbstractEventLoop ABC. I assume this was a simple mistake of omission. I will ready a PR to add it. -- components: asyncio messages: 373904 nosy: alex.gronholm, asvetlov, yselivanov

[issue41332] connect_accepted_socket() missing from AbstractEventLoop

Change by Alex Grönholm : -- keywords: +patch pull_requests: +20671 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21533 ___ Python tracker <https://bugs.python.org/issu

[issue31821] pause_reading() doesn't work from connection_made()

Change by Alex Grönholm : -- nosy: +alex.gronholm ___ Python tracker <https://bugs.python.org/issue31821> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41317] sock_accept() does not remove server socket reader on cancellation

Alex Grönholm added the comment: Sure, it should be a rather straightforward fix. I have to check if the tests for the related methods test for proper cancellation semantics. It should be even faster if they do. -- ___ Python tracker <ht

[issue41317] sock_accept() does not remove server socket reader on cancellation

Alex Grönholm added the comment: Looks like they do – fantastic! -- ___ Python tracker <https://bugs.python.org/issue41317> ___ ___ Python-bugs-list mailin

[issue41317] sock_accept() does not remove server socket reader on cancellation

Change by Alex Grönholm : -- keywords: +patch pull_requests: +20734 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21595 ___ Python tracker <https://bugs.python.org/issu

[issue40072] Win7/Python3.8/asyncio IPv6 UDP Server raise OSError when recved any packet

Alex Grönholm added the comment: I just got hit by this bug too. Attached is the repro script I came up with before finding this report. -- nosy: +alex.gronholm Added file: https://bugs.python.org/file49346/udptest.py ___ Python tracker <ht

[issue40072] Win7/Python3.8/asyncio IPv6 UDP Server raise OSError when recved any packet

Alex Grönholm added the comment: My repro script also demonstrates that when binding to an interface, the bug is not triggered. -- ___ Python tracker <https://bugs.python.org/issue40

[issue42059] TypedDict(...) as function does not respect "total" when setting __required_keys__ and __optional_keys__

New submission from Alex Grönholm : >>> DummyDict = TypedDict('DummyDict', {'x': int, 'y': str}, total=False) >>> DummyDict.__required_keys__ frozenset({'x', 'y'}) This happens because the TypedDict function does not pass

[issue42059] TypedDict(...) as function does not respect "total" when setting __required_keys__ and __optional_keys__

Change by Alex Grönholm : -- keywords: +patch pull_requests: +21699 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22736 ___ Python tracker <https://bugs.python.org/issu

[issue14352] Distutils2 won't install on Ubuntu

New submission from Alex Grönholm : Running distutils2 hg tip (changeset 2cec52b682a9): The command "pysetup install" fails with: u'Python': u'2.7.2+' is not a valid version (field 'Version') Not that it should matter, but this is Ubuntu 11.10. Also,

[issue14352] Distutils2 won't install on Ubuntu

Alex Grönholm added the comment: Being new to d2, I wouldn't know that the installation was completed successfully or if there was something left out. Regardless, this needs to be fixed. -- ___ Python tracker <http://bugs.python.org/is

[issue14352] Distutils2 won't install on Ubuntu

Alex Grönholm added the comment: It doesn't say "Warning" there, so how was I supposed to determine that it's not an error which terminated the installation process? If it is indeed just a warning, just getting rid of it would fix this for me. However, will this cause tr

[issue14352] Distutils2: add logging message to report successful installation

Alex Grönholm added the comment: > I’m not sure why you’re asking that, as d2’s setup.cfg does not use > requires-python and does produce the warning, so it’s unrelated. (The > warning comes from d2.database.) I was concerned that maybe the version comparator would barf on a ver

[issue14356] Distutils2 ignores site-local configuration

New submission from Alex Grönholm : Distutils2 seems to rely solely on a sysconfig.cfg shipped with distutils2 to get the path where to install packages. Ignoring site-local configuration means that it won't work on Python distributions where the site configuration has been customized

[issue14357] Distutils2 does not work with virtualenv

New submission from Alex Grönholm : The installed pysetup script launches (at least on my system) with /usr/bin/python regardless of the interpreter used for installing it. -- assignee: eric.araujo components: Distutils2 messages: 156231 nosy: agronholm, alexis, eric.araujo, tarek

[issue14357] Distutils2 does not work with virtualenv

Changes by Alex Grönholm : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue14357> ___ ___ Python-bugs-list mailing list Unsubscri

[issue14357] Distutils2 does not work with virtualenv

Alex Grönholm added the comment: Log attached. -- Added file: http://bugs.python.org/file24927/d2log.txt ___ Python tracker <http://bugs.python.org/issue14

[issue14356] Distutils2 ignores site-local configuration

Alex Grönholm added the comment: >The supposed way to work, for OS packagers, is to ship this >sysconfig.cfg thing. Even for Pythons older than 3.3? -- ___ Python tracker <http://bugs.python.org/i

[issue14357] Distutils2 does not work with virtualenv

Alex Grönholm added the comment: >I can’t reproduce. Can you delete your venv, start again and tell me how it >goes? I've repeated this several times, and the result is always the same. -- ___ Python tracker <http://bugs.python.

[issue14356] Distutils2 ignores site-local configuration

Alex Grönholm added the comment: >If I understand correctly that you used “/usr/bin/python pysetup install spam” >and wanted it to install to /usr/lib/python2.7/site-packages, then I think >that the correct reply is: Not supported, don’t do that. If you did something >else, plea

[issue14356] Distutils2 ignores site-local configuration

Alex Grönholm added the comment: >> Ignoring site-local configuration >What do you mean? sitecustomize is executed, for example. Whatever, but it only looks for the paths in the included sysconfig.cfg. If the system Python uses a different sort of path in site.py, distutils2 won

[issue14357] Distutils2 does not work with virtualenv

Alex Grönholm added the comment: Kubuntu 11.10, 64-bit. No ~/.pydistutils.cfg. What other info do you need? -- ___ Python tracker <http://bugs.python.org/issue14

[issue36999] Expose the coroutine object in asyncio task objects

New submission from Alex Grönholm : Both curio and trio expose the coroutine object belonging to a task as the "coro" attribute. Asyncio exposes this as "_coro" (as does uvloop) but it would be nice to have at least a read-only attribute exposing this as part of the public

[issue36999] Expose the coroutine object in asyncio task objects

Alex Grönholm added the comment: I'll look into making a PR. -- ___ Python tracker <https://bugs.python.org/issue36999> ___ ___ Python-bugs-list m

[issue36999] Expose the coroutine object in asyncio task objects

Change by Alex Grönholm : -- keywords: +patch pull_requests: +13568 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13680 ___ Python tracker <https://bugs.python.org/issu

[issue34270] Add names to asyncio tasks

New submission from Alex Grönholm : Having names on tasks helps tremendously when something goes wrong in a complex asyncio application. Threads have names and even trio has the ability to name its tasks. This would also greatly benefit PyCharm's concurrency visualization:

[issue34270] Add names to asyncio tasks

Alex Grönholm added the comment: I also couldn't figure out yet why PyUnicode_Check() was necessary in the first place. Doesn't PyObject_Str() just increment the refcount if the argument is already a string? Eric, please explain why these changes shou

[issue34270] Add names to asyncio tasks

Alex Grönholm added the comment: Yury, I have no objections. Furthermore, it would be nice to expose the coroutine object publicly, like curio and trio do. It would make life simpler for me in some cases. -- ___ Python tracker <ht

[issue34270] Add names to asyncio tasks

Alex Grönholm added the comment: Ok, I understand. But is the conversion a bad thing then? -- ___ Python tracker <https://bugs.python.org/issue34270> ___ ___

[issue34270] Add names to asyncio tasks

Alex Grönholm added the comment: > It's not a bad thing, it's just that we don't do it in C Task and we do it in > pure Python Task. Eric wants us to synchronize them so that in a very > unlikely scenario where someone uses subclasses of str for names they will >

[issue34270] Add names to asyncio tasks

Alex Grönholm added the comment: Which way do we want to change this? Do we want to convert to pure strings or retain the original object? In the latter case both the C and Python implementations (including set_name()) have to be changed

[issue34270] Add names to asyncio tasks

Alex Grönholm added the comment: > On the other had, the matter is made moot by using PyUnicode_CheckExact() Then, in order to keep the pure Python implementation in sync, we'd have to change it to something like this: if name is None: self._name = f'Task-{_task_name_cou

[issue34270] Add names to asyncio tasks

Alex Grönholm added the comment: > Please just change PyUnicode_Check to PyUnicode_CheckExact in C Task.__init__ > and use the same if check in C Task.set_name. I'll do that if you say so, but I'm just saying that the C and Python implementations will still remain different i

[issue34270] Add names to asyncio tasks

Alex Grönholm added the comment: > I'll do that if you say so, but I'm just saying that the C and Python implementations will still remain different in semantics then. Never mind, that was a brain fart. I keep ignoring the &

[issue34270] Add names to asyncio tasks

Change by Alex Grönholm : -- pull_requests: +8202 ___ Python tracker <https://bugs.python.org/issue34270> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14747] Classifiers are missing from distutils2-generated metadata

New submission from Alex Grönholm : Apparently they worked in 1.0a3 but not in 1.0a4 anymore. -- assignee: eric.araujo components: Distutils2 messages: 160184 nosy: agronholm, alexis, eric.araujo, tarek priority: normal severity: normal status: open title: Classifiers are missing from

[issue8668] Packaging: add a 'develop' command

Alex Grönholm added the comment: Python 3.3 is entering beta soon. The develop command is a must have, especially now that virtualenv is part of the official Python distribution. Can someone summarize what still needs to be done to get this feature merged? -- nosy: +agronholm

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Changes by Alex Grönholm : -- nosy: +alex.gronholm ___ Python tracker <http://bugs.python.org/issue20737> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue6126] Python 3 pdb: shows internal code, breakpoints don't work

Alex Grönholm added the comment: Why has this not been resolved yet? Not having a working debugger is a severe hindrance to the acceptance of Py3k. -- nosy: +agronholm ___ Python tracker <http://bugs.python.org/issue6

[issue23242] asyncio: Process must close the transport when the process exit

Changes by Alex Grönholm : -- nosy: +alex.gronholm versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue23242> ___ ___ Python-bugs-list mailin

[issue23242] asyncio: Process must close the transport when the process exit

Alex Grönholm added the comment: Are you sure this has been fixed? The attached script reproduces the bug 100% reliably on my laptop. -- Added file: http://bugs.python.org/file46198/read_subprocess.py ___ Python tracker <http://bugs.python.

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Alex Grönholm added the comment: Was __await__() deliberately left out of concurrent.futures.Future or was that an oversight? Or am I misunderstanding something? -- nosy: +alex.gronholm ___ Python tracker <http://bugs.python.org/issue24

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: Yes, Yury's approach is wrong here -- Futures should not know about asyncio, but asyncio should be able to handle Futures natively. This seems like the obvious solution to me. Any counterarguments? -- nosy: +alex.gro

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: Sorry to keep you waiting. This sample code runs fine with the attached patch: https://gist.github.com/agronholm/43c71be0028bb866753a In short, I implemented support for concurrent.futures in the asyncio Task class instead of making concurrent.futures aware of

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: I think concurrent.futures.Future warrants adding support for in Task. It predates asyncio and is generic enough. Can you elaborate on what other types you would want to support as awaitables in Task? -- ___ Python

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: I agree with Stefan and Yury. As for the tests, Yury seemed to have those in his patches -- I'll take a look and see if they're directly applicable. For Python 3.5 and earlier, there is a workaround to awaiting for concurrent Futures, but it requir

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: Yury, your tests complete even without any patches on cpython default (@74fc1af57c72). How is that possible? I verified that they are run. -- ___ Python tracker <http://bugs.python.org/issue24

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: Nevermind, I was running the wrong Python version. -- ___ Python tracker <http://bugs.python.org/issue24383> ___ ___ Python-bug

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: I'm having trouble compiling the latest default (@859a45ca1e86). Getting linker errors. I've updated the patch with Yury's tests in it. Would someone mind running them? Apparently they do pass on

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: Ah hehe, I forgot to actually attach the patch. Thanks Yury. The asyncio docs need to explicitly mention that concurrent.futures.Futures can be directly awaited from coroutines. Aside from that, I think we're set -- just need Guido to chime in on

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: You're right Stefan -- I too was appalled that this was not possible in 3.5 to begin with. It feels completely natural to be able to await for concurrent Futures. But as this is considered a feature, it'll probably have to wait until 3.6. Otherwise

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: Updated patch per review comments. I also corrected the order of the lines in the new block. If _must_cancel is True, it would have tried to call cancel() on _fut_waiter before it was set. Now the code matches that of the original block. The docs don't

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: +1. It was specifically SQLAlchemy (but not limited to it -- there are many other blocking APIs) that made me look for a way to easily use threads with native coroutines. The best workaround I've come up with: from asyncio import wrap_future async de

[issue24785] Document asyncio.futures.wrap_future()

New submission from Alex Grönholm: Since Python 3.5 will not support awaiting for concurrent.futures.Futures natively, one has to use the asyncio.futures.wrap_future() function in coroutines like this: async def foo(): await wrap_future(executor.submit(...)) The wrap_future() function is

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: Created issue 24785 for the documentation of wrap_future(). -- ___ Python tracker <http://bugs.python.org/issue24383> ___ ___

[issue24755] asyncio.wrap_future undocumented

Changes by Alex Grönholm : -- nosy: +alex.gronholm ___ Python tracker <http://bugs.python.org/issue24755> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: Why do you want to keep threads separate from asyncio? What's the downside here? The use of helper functions is justifiable when integrating a third party framework or similar with asyncio, but standard library components should just integrate well with

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: Where do we stand with this then? Should I start a thread on python-dev to get the ball rolling? -- ___ Python tracker <http://bugs.python.org/issue24

[issue24383] consider implementing __await__ on concurrent.futures.Future

Alex Grönholm added the comment: I've already made my case on python-ideas, so let's talk it over there. -- ___ Python tracker <http://bugs.python.o

[issue23749] asyncio missing wrap_socket (starttls)

Changes by Alex Grönholm : -- nosy: +alex.gronholm ___ Python tracker <http://bugs.python.org/issue23749> ___ ___ Python-bugs-list mailing list Unsubscribe:

  1   2   >