[issue47071] asyncio proactor udp transport stops responding after send to port that isn't listening
Erik Soma added the comment: Certainly: https://github.com/python/cpython/pull/32011 -- ___ Python tracker <https://bugs.python.org/issue47071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47071] asyncio proactor udp transport stops responding after send to port that isn't listening
Change by Erik Soma : -- keywords: +patch pull_requests: +30099 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32011 ___ Python tracker <https://bugs.python.org/issue47071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47071] asyncio proactor udp transport stops responding after send to port that isn't listening
Erik Soma added the comment: Uploading my hack to `asyncio.windows_events.py` -- this is based off 3.10.2's distribution. -- Added file: https://bugs.python.org/file50692/windows_events.py ___ Python tracker <https://bugs.python.org/issue47071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47071] asyncio proactor udp transport stops responding after send to port that isn't listening
New submission from Erik Soma : Reproducer attached. Change `USE_PROACTOR` to `False` to use the `SelectorEventLoop` instead, which doesn't exhibit this behavior. The output on my machine when using the proactor loop is: ``` datagram received b'ping 1' datagram received b'ping 2' ``` And the selector loop (which is the behavior I would expect): ``` datagram received b'ping 1' datagram received b'ping 2' datagram received b'ping 3' ``` At a high level, after sending data to an address that isn't listening the asyncio protocol will no longer receive messages. Digging deeper, `_ProactorDatagramTransport._loop_reading` encounters the windows error 1234 (ERROR_PORT_UNREACHABLE) after the "bad send". It appears this a (undocumented/buggy?) behavior of `WSARecvFrom` where the next call to it after an unreachable `WSASendTo` in UDP mode will return the ICMP unreachable message. The actual error is returned from `GetOverlappedResult`. I've hacked together a fix that retries `IocpProactor.recvfrom` if the result is ERROR_PORT_UNREACHABLE. It fixes the issue for the reproducer and my actual use case, but it's probably not ideal. My solution for the moment is just to use the SelectorEventLoop instead. -- components: Windows, asyncio files: udpbug2.py messages: 415611 nosy: asvetlov, esoma, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: asyncio proactor udp transport stops responding after send to port that isn't listening versions: Python 3.10 Added file: https://bugs.python.org/file50691/udpbug2.py ___ Python tracker <https://bugs.python.org/issue47071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43310] Method __del__ with callable
Erik Soma added the comment: You can wrap your callable in a regular function: ``` def hack_c(): c = C() def _(*args, **kwargs): return c(*args, **kwargs) return _ A.__del__ = hack_c() ``` Or (untested) make your callable an extension type with Py_TPFLAGS_METHOD_DESCRIPTOR. Or instead of monkey-patching __del__ make __del__ call it: ``` class A: my_del = lambda *args, **kwargs: None def __del__(self): self.my_del(self) A.my_del = C() ``` This doesn't just apply to __del__, other dunders exhibit this behavior as well. It is unintuitive, but I'm pretty sure it's not a bug. -- nosy: +esoma ___ Python tracker <https://bugs.python.org/issue43310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42840] `type` takes **kwargs for __init_subclass__
Erik Soma added the comment: The CPython PR has gone stale waiting for core review, pinging this per the dev guide. -- ___ Python tracker <https://bugs.python.org/issue42840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42840] `type` takes **kwargs for __init_subclass__
Erik Soma added the comment: Seems I misframed the issue a bit. I didn't realize keyword arguments besides 'metaclass' were introduced with PEP 3115 with Python 3.0. In any case I've posted a PR to update the docs and typeshed. Typeshed PR for reference: https://github.com/python/typeshed/pull/4918 -- ___ Python tracker <https://bugs.python.org/issue42840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42840] `type` takes **kwargs for __init_subclass__
Change by Erik Soma : -- keywords: +patch pull_requests: +23000 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24173 ___ Python tracker <https://bugs.python.org/issue42840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42840] `type` takes **kwargs for __init_subclass__
Erik Soma added the comment: Can do. I have found a blurb in the 3.6 What's New that confirms it was purposeful (https://docs.python.org/3/whatsnew/3.6.html#index-37). -- ___ Python tracker <https://bugs.python.org/issue42840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42840] `type` takes **kwargs for __init_subclass__
New submission from Erik Soma :
The documentation (https://docs.python.org/3/library/functions.html#type) shows
type's signature as:
class type(object)
class type(name, bases, dict)
But the "actual" 2nd signature in CPython 3.6+ is:
class type(name, bases, dict, **kwargs)
**kwargs here gets passed to __init_subclass__ in the same way that keywords in
a class statement do so that:
type("Bar", (Foo,), {}, spam='ham')
is equivalent to
class Bar(Foo, spam='ham'): pass
It's not clear to me whether this is behavior to rely on. I started using this
intuitively, but found that my type checker reasonably complained.
Looking through the commit that implemented PEP 487 (d78448e9), it seems this
may have been incidental. Additionally I haven't found mention of this in PEP
487 or the documentation and I can't seem to find any tests for it.
--
messages: 384506
nosy: esoma
priority: normal
severity: normal
status: open
title: `type` takes **kwargs for __init_subclass__
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42840>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42687] tokenize module does not recognize Barry as FLUFL
Change by Erik Soma : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42687] tokenize module does not recognize Barry as FLUFL
Change by Erik Soma : -- keywords: +patch pull_requests: +22722 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23857 ___ Python tracker <https://bugs.python.org/issue42687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42687] tokenize module does not recognize Barry as FLUFL
New submission from Erik Soma : '<>' is not recognized by the tokenize module as a single token, instead it is two tokens. ``` $ python -c "import tokenize; import io; import pprint; pprint.pprint(list(tokenize.tokenize(io.BytesIO(b'<>').readline)))" [TokenInfo(type=62 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line=''), TokenInfo(type=54 (OP), string='<', start=(1, 0), end=(1, 1), line='<>'), TokenInfo(type=54 (OP), string='>', start=(1, 1), end=(1, 2), line='<>'), TokenInfo(type=4 (NEWLINE), string='', start=(1, 2), end=(1, 3), line=''), TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')] ``` I would expect: ``` [TokenInfo(type=62 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line=''), TokenInfo(type=54 (OP), string='<>', start=(1, 0), end=(1, 2), line='<>'), TokenInfo(type=4 (NEWLINE), string='', start=(1, 2), end=(1, 3), line=''), TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')] ``` This is the behavior of the CPython tokenizer which the tokenizer module tries "to match the working of". -- messages: 383384 nosy: esoma priority: normal severity: normal status: open title: tokenize module does not recognize Barry as FLUFL versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
