[issue40897] Inheriting from class that defines __new__ causes inspect.signature to always return (*args, **kwargs) for constructor
Jonathan Slenders added the comment: The following patch to inspect.py solves the issue that inspect.signature() returns the wrong signature on classes that inherit from Generic. Not 100% sure though if this implementation is the cleanest way possible. I've been looking into attaching a __wrapped__ to Generic as well, without success. I'm not very familiar with the inspect code. To me, this fix is pretty important. ptpython, a Python REPL, has the ability to show the function signature of what the user is currently typing, and with codebases that have lots of generics, there's nothing really useful we can show. $ diff inspect.old.py inspect.py -p *** inspect.old.py 2021-02-17 11:35:50.787234264 +0100 --- inspect.py 2021-02-17 11:35:10.131407202 +0100 *** import sys *** 44,49 --- 44,50 import tokenize import token import types + import typing import warnings import functools import builtins *** def _signature_get_user_defined_method(c *** 1715,1720 --- 1716,1725 except AttributeError: return else: + if meth in (typing.Generic.__new__, typing.Protocol.__new__): + # Exclude methods from the typing module. + return + if not isinstance(meth, _NonUserDefinedCallables): # Once '__signature__' will be added to 'C'-level # callables, this check won't be necessary *** For those interested, the following monkey-patch has the same effect: def monkey_patch_typing() -> None: import inspect, typing def _signature_get_user_defined_method(cls, method_name): try: meth = getattr(cls, method_name) except AttributeError: return else: if meth in (typing.Generic.__new__, typing.Protocol.__new__): # Exclude methods from the typing module. return if not isinstance(meth, inspect._NonUserDefinedCallables): # Once '__signature__' will be added to 'C'-level # callables, this check won't be necessary return meth inspect._signature_get_user_defined_method = _signature_get_user_defined_method monkey_patch_typing() -- nosy: +jonathan.slenders ___ Python tracker <https://bugs.python.org/issue40897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39010] ProactorEventLoop raises unhandled ConnectionResetError
Jonathan Slenders added the comment: Even simpler, the following code will crash after so many iterations: ``` import asyncio loop = asyncio.get_event_loop() while True: loop.call_soon_threadsafe(loop.stop) loop.run_forever() ``` Adding a little sleep of 0.01s after `run_forever()` prevents the issue. So, to me it looks like the cancellation of the `_OverlappedFuture` that wraps around the `_recv()` call from the self-pipe did not complete before we start `_recv()` again in the next `run_forever()` call. No idea if that makes sense... -- ___ Python tracker <https://bugs.python.org/issue39010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39010] ProactorEventLoop raises unhandled ConnectionResetError
Jonathan Slenders added the comment: It looks like the following code will reproduce the issue: ``` import asyncio import threading loop = asyncio.get_event_loop() while True: def test(): loop.call_soon_threadsafe(loop.stop) threading.Thread(target=test).start() loop.run_forever() ``` Leave it running on Windows, in Python 3.8 for a few seconds, then it starts spawning `ConnectionResetError`s. -- ___ Python tracker <https://bugs.python.org/issue39010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39010] ProactorEventLoop raises unhandled ConnectionResetError
Jonathan Slenders added the comment: Thanks Victor for the reply. It looks like it's the self-socket in the BaseProactorEventLoop that gets closed. It's exactly this FD for which the exception is raised. We don't close the event loop anywhere. I also don't see `_close_self_pipe` being called anywhere. Debug logs don't provide any help. I'm looking into a reproducer. -- ___ Python tracker <https://bugs.python.org/issue39010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39010] ProactorEventLoop raises unhandled ConnectionResetError
Jonathan Slenders added the comment: Suppressing `ConnectionResetError` in `BaseProactorEventLoop._loop_self_reading`, like we do with `CancelledError` seems to fix it. Although I'm not sure what it causing the error, and whether we need to handle it somehow. -- ___ Python tracker <https://bugs.python.org/issue39010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39010] ProactorEventLoop raises unhandled ConnectionResetError
New submission from Jonathan Slenders :
We have a snippet of code that runs perfectly fine using the
`SelectorEventLoop`, but crashes *sometimes* using the `ProactorEventLoop`.
The traceback is the following. The exception cannot be caught within the
asyncio application itself (e.g., it is not attached to any Future or
propagated in a coroutine). It probably propagates in `run_until_complete()`.
File "C:\Python38\lib\asyncio\proactor_events.py", line 768, in
_loop_self_reading
f.result() # may raise
File "C:\Python38\lib\asyncio\windows_events.py", line 808, in _poll
value = callback(transferred, key, ov)
File "C:\Python38\lib\asyncio\windows_events.py", line 457, in finish_recv
raise ConnectionResetError(*exc.args)
I can see that in `IocpProactor._poll`, `OSError` is caught and attached to the
future, but not `ConnectionResetError`. I would expect that
`ConnectionResetError` too will be attached to the future.
In order to reproduce, run the following snippet on Python 3.8:
from prompt_toolkit import prompt # pip install prompt_toolkit
while 1:
prompt('>')
Hold down the enter key, and it'll trigger quickly.
See also: https://github.com/prompt-toolkit/python-prompt-toolkit/issues/1023
--
components: asyncio
messages: 358140
nosy: Jonathan Slenders, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: ProactorEventLoop raises unhandled ConnectionResetError
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue39010>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24536] os.pipe() should return a structsequence (or namedtuple.)
New submission from Jonathan Slenders: As discussed on python-ideas, os.pipe should return a structsequence instead of a plain tuple. To be decided is the naming for the read and write end. Personally, I'm in favour of using readfd/writefd. our_pipe = pipe() os.write(our_pipe.writefd, b'data') os.read(our_pipe.readfd, 1024) -- components: IO messages: 245980 nosy: jonathan.slenders priority: normal severity: normal status: open title: os.pipe() should return a structsequence (or namedtuple.) versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24536 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24536] os.pipe() should return a structsequence (or namedtuple.)
Jonathan Slenders added the comment: Niki Spahiev made a valid argument saying that the following code is common: if not hasattr(src, 'read'): src = open(src) This will break if we name it 'read'/'write' like the methods of a file object. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24536 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
