[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Adrian Garcia Badaracco added the comment: I am not sure if that solves anything (other than the fact that __new__ is much less common to implement than __init__), but I may just be slow to pick up the implications of moving the check to __new__

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Adrian Garcia Badaracco added the comment: Guido, it looks like you replied while I was typing my reply out. Yurii can correct me here but I believe PR #27543 was an attempt to disallow defining `__init__` on a Protocol completely. What I proposed above is the opposite behavior, while still

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Adrian Garcia Badaracco added the comment: Agreed. What if we allow protocols that implement `__init__` but still disallow instantiating a protocol that does not? It's a 1 line change, all existing tests pass and it would still catch what I think was the original intention (trying

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Change by Adrian Garcia Badaracco : -- pull_requests: +29750 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/31628 ___ Python tracker <https://bugs.python.org/issu

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Adrian Garcia Badaracco added the comment: Apologies if that was noise, I filed an issue on the MyPy issue tracker: https://github.com/python/mypy/issues/12261 -- ___ Python tracker <https://bugs.python.org/issue44

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Adrian Garcia Badaracco added the comment: While this is figured out, would it be possible to remove the silent overriding? This seems like something type checkers should be doing, not silent runtime modification of classes. Pyright already (correctly) checks this, so I think it would just

[issue17005] Add a topological sort algorithm

Adrian Garcia Badaracco added the comment: As part of working on a tool that deals with dependencies, I was building my own topological sort. I iterated through various APIs (iterable of tasks, iterable of parallelizable groups of tasks, etc.) until I found the (now stdlib) version which

[issue26175] Fully implement IOBase abstract on SpooledTemporaryFile

Change by Adrian Garcia Badaracco : -- nosy: +adriangb ___ Python tracker <https://bugs.python.org/issue26175> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44834] contextvars.Context.run w/ coroutines gives inconsistent behavior

Change by Adrian Garcia Badaracco : -- nosy: +yselivanov ___ Python tracker <https://bugs.python.org/issue44834> ___ ___ Python-bugs-list mailing list Unsub

[issue42815] new thread doesn't copy context of the parent thread

Change by Adrian Garcia Badaracco : -- nosy: +adriangb ___ Python tracker <https://bugs.python.org/issue42815> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44834] contextvars.Context.run w/ coroutines gives inconsistent behavior

New submission from Adrian Garcia Badaracco : I recently tried to use `contextvars.Context.run` w/ coroutines, expecting the same behavior as with regular functions, but it seems that `contextvars.Context.run` does not work w/ coroutines. I'm sorry if this is something obvious to do with how