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

2009-08-09 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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 rep...@bugs.python.org http

[issue8668] Packaging: add a 'develop' command

2012-06-13 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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

[issue14352] Distutils2 won't install on Ubuntu

2012-03-17 Thread Alex Grönholm
New submission from Alex Grönholm alex.gronholm+pyt...@nextday.fi: 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, distutils2

[issue14352] Distutils2 won't install on Ubuntu

2012-03-17 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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 rep

[issue14352] Distutils2 won't install on Ubuntu

2012-03-17 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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

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

2012-03-17 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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

[issue14356] Distutils2 ignores site-local configuration

2012-03-18 Thread Alex Grönholm
New submission from Alex Grönholm alex.gronholm+pyt...@nextday.fi: 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

[issue14357] Distutils2 does not work with virtualenv

2012-03-18 Thread Alex Grönholm
New submission from Alex Grönholm alex.gronholm+pyt...@nextday.fi: 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

[issue14357] Distutils2 does not work with virtualenv

2012-03-18 Thread Alex Grönholm
Changes by Alex Grönholm alex.gronholm+pyt...@nextday.fi: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14357 ___ ___ Python

[issue14357] Distutils2 does not work with virtualenv

2012-03-18 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi added the comment: Log attached. -- Added file: http://bugs.python.org/file24927/d2log.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14357

[issue14356] Distutils2 ignores site-local configuration

2012-03-18 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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 rep...@bugs.python.org http://bugs.python.org

[issue14357] Distutils2 does not work with virtualenv

2012-03-18 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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 rep

[issue14356] Distutils2 ignores site-local configuration

2012-03-18 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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

[issue14356] Distutils2 ignores site-local configuration

2012-03-20 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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

[issue14357] Distutils2 does not work with virtualenv

2012-03-22 Thread Alex Grönholm
Alex Grönholm alex.gronholm+pyt...@nextday.fi added the comment: Kubuntu 11.10, 64-bit. No ~/.pydistutils.cfg. What other info do you need? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14357

[issue14747] Classifiers are missing from distutils2-generated metadata

2012-05-07 Thread Alex Grönholm
New submission from Alex Grönholm alex.gronholm+pyt...@nextday.fi: 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

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

2014-02-24 Thread Alex Grönholm
Changes by Alex Grönholm alex.gronholm+pyt...@nextday.fi: -- nosy: +alex.gronholm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20737

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

2015-06-03 Thread Alex Grönholm
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 rep...@bugs.python.org http

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

2015-08-03 Thread Alex Grönholm
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 each

[issue24900] Raising an exception that cannot be unpickled causes hang in ProcessPoolExecutor

2015-08-20 Thread Alex Grönholm
Changes by Alex Grönholm alex.gronholm+pyt...@nextday.fi: -- nosy: +alex.gronholm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24900

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

2015-08-20 Thread Alex Grönholm
Alex Grönholm added the comment: I've implemented my background-calling code in my framework via run_in_executor() now, so this has become a non-issue for me. I have no more interest in this patch. -- ___ Python tracker rep...@bugs.python.org http

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

2015-08-01 Thread Alex Grönholm
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 requires the use

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

2015-08-02 Thread Alex Grönholm
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 3.5b3 at least

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

2015-08-02 Thread Alex Grönholm
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 rep...@bugs.python.org http://bugs.python.org

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

2015-08-02 Thread Alex Grönholm
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

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

2015-08-02 Thread Alex Grönholm
Alex Grönholm added the comment: Nevermind, I was running the wrong Python version. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383

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

2015-08-02 Thread Alex Grönholm
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 you'll end

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

2015-08-02 Thread Alex Grönholm
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 seem

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

2015-07-31 Thread Alex Grönholm
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

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

2015-08-01 Thread Alex Grönholm
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

[issue24755] asyncio.wrap_future undocumented

2015-08-03 Thread Alex Grönholm
Changes by Alex Grönholm alex.gronholm+pyt...@nextday.fi: -- nosy: +alex.gronholm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24755

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

2015-08-07 Thread Alex Grönholm
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 rep...@bugs.python.org http://bugs.python.org/issue24383

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

2015-08-07 Thread Alex Grönholm
Alex Grönholm added the comment: I've already made my case on python-ideas, so let's talk it over there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383

[issue23749] asyncio missing wrap_socket (starttls)

2015-08-12 Thread Alex Grönholm
Changes by Alex Grönholm alex.gronholm+pyt...@nextday.fi: -- nosy: +alex.gronholm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23749

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

2015-07-24 Thread Alex Grönholm
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.gronholm

[issue26075] typing.Union unifies types too broadly

2016-01-10 Thread Alex Grönholm
New submission from Alex Grönholm: >>> from typing import Union, Iterable >>> Union[str, Iterable[int]] typing.Iterable[int] The union loses the "str" parameter because issubclass(str, collections.abc.Iterable) returns True and the check completely disregards

[issue26477] typing forward references and module attributes

2016-03-03 Thread Alex Grönholm
Alex Grönholm added the comment: I wonder why they forward references are evaluated *at all* at this point. Seems senseless to me. This should be the job of the static type checker or the get_type_hints() function. -- nosy: +alex.gronholm

[issue23749] asyncio missing wrap_socket (starttls)

2016-09-17 Thread Alex Grönholm
Alex Grönholm added the comment: So is this going to make it into 3.6...? -- nosy: +Alex Grönholm ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue28453] SSLObject.selected_alpn_protocol() not documented

2016-10-15 Thread Alex Grönholm
New submission from Alex Grönholm: the ssl.SSLObject class supports selected_alpn_protocol() like ssl.SSLSocket, but it is not mentioned on the list of supported methods. -- assignee: christian.heimes components: SSL messages: 278739 nosy: alex.gronholm, christian.heimes priority

[issue28453] SSLObject.selected_alpn_protocol() not documented

2016-10-16 Thread Alex Grönholm
Alex Grönholm added the comment: HTTP/2 (h2) is kind of a biggie :) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28453> ___ ___

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

2017-01-07 Thread Alex Grönholm
Changes by Alex Grönholm <alex.gronholm+pyt...@nextday.fi>: -- nosy: +alex.gronholm versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

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

2017-01-07 Thread Alex Grönholm
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 <rep...@bugs.python.

[issue34270] Add names to asyncio tasks

2018-07-29 Thread Alex Grönholm
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: https

[issue34270] Add names to asyncio tasks

2018-08-09 Thread Alex Grönholm
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

2018-08-09 Thread Alex Grönholm
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_counter()}' e

[issue34270] Add names to asyncio tasks

2018-08-09 Thread Alex Grönholm
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 should be done

[issue34270] Add names to asyncio tasks

2018-08-09 Thread Alex Grönholm
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

2018-08-09 Thread Alex Grönholm
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 > have exact sa

[issue34270] Add names to asyncio tasks

2018-08-09 Thread Alex Grönholm
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

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

[issue34270] Add names to asyncio tasks

2018-08-09 Thread Alex Grönholm
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 "!&quo

[issue34270] Add names to asyncio tasks

2018-08-09 Thread Alex Grönholm
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 in sem

[issue36999] Expose the coroutine object in asyncio task objects

2019-05-30 Thread Alex Grönholm
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

[issue36999] Expose the coroutine object in asyncio task objects

2019-05-21 Thread Alex Grönholm
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

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

[issue37542] UDP sendto() sends duplicate packets

2019-12-27 Thread Alex Grönholm
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

2019-12-28 Thread Alex Grönholm
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

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

[issue40213] contextlib.aclosing()

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

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

2020-04-28 Thread Alex Grönholm
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's such a b

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

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

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

2020-04-23 Thread Alex Grönholm
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

2020-04-23 Thread Alex Grönholm
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.org/issue39

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

2020-05-17 Thread Alex Grönholm
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/issue39

[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop

2020-03-23 Thread Alex Grönholm
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

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

2020-10-17 Thread Alex Grönholm
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

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

2020-10-17 Thread Alex Grönholm
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 the "total" metaclass argument to _Type

[issue40213] contextlib.aclosing()

2020-07-03 Thread Alex Grönholm
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/issue40

[issue40213] contextlib.aclosing()

2020-07-03 Thread Alex Grönholm
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.

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

2020-07-22 Thread Alex Grönholm
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

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

2020-07-17 Thread Alex Grönholm
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

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

2020-07-29 Thread Alex Grönholm
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

2020-07-29 Thread Alex Grönholm
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

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

2020-07-19 Thread Alex Grönholm
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

2020-07-22 Thread Alex Grönholm
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

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

[issue41332] connect_accepted_socket() missing from AbstractEventLoop

2020-07-18 Thread Alex Grönholm
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

2020-07-18 Thread Alex Grönholm
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

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

2020-07-16 Thread Alex Grönholm
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 removed