[issue43253] asyncio open_connection fails when a socket is explicitly closed

Maximilian Hils added the comment: Thank you for the super quick turnaround. My heart goes out to you and everyone else in Ukraine. -- ___ Python tracker <https://bugs.python.org/issue43

[issue43253] asyncio open_connection fails when a socket is explicitly closed

Change by Maximilian Hils : -- pull_requests: +29990 pull_request: https://github.com/python/cpython/pull/31892 ___ Python tracker <https://bugs.python.org/issue43

[issue47014] ProactorEventLoop ignores Ctrl+C after closing unrelated loop

New submission from Maximilian Hils : When a (second) ProactorEventLoop is garbage-collected, the current ProactorEventLoop starts to ignore Ctrl+C on Windows until it is woken up. The attached repro shows a minimal example. Uncommenting the `create_task` call or not using a second event

[issue43253] asyncio open_connection fails when a socket is explicitly closed

Maximilian Hils added the comment: asvetlov: Sorry if I articulated myself badly, but I do think this is a valid bug. It's unfortunately hard to provide a better repro (I tried), but we are hitting this regularly when mitmproxy is accepting connections under heavy load. We're just calling

[issue43253] asyncio open_connection fails when a socket is explicitly closed

Change by Maximilian Hils : -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue43253> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43253] asyncio open_connection fails when a socket is explicitly closed

Maximilian Hils added the comment: We are hitting the same traceback with mitmproxy on Windows without ever passing a socket object to open_connection. In other words, this can be triggered without performing any action on 'sock' due to some race conditions in the Windows network stack. I

[issue40124] Clearer assertion error

Maximilian Hils added the comment: I'm pretty sure this issue is a duplicate of bpo-issue29930. -- nosy: +mhils versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue40

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Change by Maximilian Hils : -- keywords: +patch pull_requests: +26317 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27859 ___ Python tracker <https://bugs.python.org/issu

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Maximilian Hils added the comment: Thanks Guido! I agree on not pursuing the List["Foo"] case for the reasons you mentioned. Let me know if you think it'd be useful to mention this limitation briefly in one of the relevant PEPs or somewhere else. I'm not sure if it mee

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Maximilian Hils added the comment: Thank you Ken and Guido for the super quick feedback! > It's not fine if it were to look in the wrong namespace That's a really good point. Here's another terrible example: foo.py: ``` import typing FooData: typing.TypeAlias = "Data"

[issue44587] argparse BooleanOptionalAction displays default=SUPPRESS unlike other action types

Change by Maximilian Hils : -- keywords: +patch nosy: +mhils nosy_count: 2.0 -> 3.0 pull_requests: +26259 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27672 ___ Python tracker <https://bugs.python.org/i

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Maximilian Hils added the comment: @Guido van Rossum: Yes, GH-27017 is the same as #41249 in the initial post. There are also some cases where we don't even have a ForwardRef though: foo.py: ``` import typing FooType: typing.TypeAlias = "Foo" class Foo: pass ``` bar.py:

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Maximilian Hils added the comment: > For your specific use case (where the user is using Python 3.6), you could > pass in globalns and localns to get_type_hints as a temporary workaround. Off > the top of my head: get_type_hints(func2, globalns=foo.__dict__) might work. Would

[issue44926] typing.get_type_hints() raises for type aliases with forward references

New submission from Maximilian Hils : Someone reported this rather interesting issue where typing.get_type_hints crashes on type aliases with forward references. The original report is at https://github.com/mitmproxy/pdoc/issues/290. Here's an extended minimal example: foo.py: ``` import

[issue38956] argparse.BooleanOptionalAction should not add the default value to the help string by default

Change by Maximilian Hils : -- nosy: +mhils nosy_count: 5.0 -> 6.0 pull_requests: +26160 pull_request: https://github.com/python/cpython/pull/27672 ___ Python tracker <https://bugs.python.org/issu

[issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4

Maximilian Hils added the comment: Thanks for the insanely quick feedback. I still think this is a bug, so I filed https://bugs.python.org/issue29515 with additional details. Let's continue there. -- ___ Python tracker <rep...@bugs.python.

[issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows

New submission from Maximilian Hils: The latest Windows builds for Python 3.5.3/3.6.0 do not export socket.IPPROTO_IPV6, even though e.g. socket.IPV6_V6ONLY is exported. This seems to be wrong to me as IPV6_V6ONLY requires the corresponding socket option level IPPROTO_IPV6 to be actually

[issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4

Maximilian Hils added the comment: This still seems to be an issue with the offical Python 3.6 builds on Windows 10: Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32 >>> import socket >>> socket.IPPROTO_IPV6 Traceback (mos