Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 2k
Add @disjoint_base decorator in the stdlib#14599
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
Conversation
This comment has been minimized.
This comment has been minimized.
AlexWaygood commented Aug 20, 2025
I almost wonder if it's worth adding a variant @disjoint_base_if(sys.version_info< (3, 11))classFoo(tuple): ...Maybe that would just be overcomplicating the proposal, though |
JelleZijlstra commented Aug 20, 2025
I've been thinking about a more general version, where we add a do-nothing identity decorator so you can write Pyright seems very unhappy here presumably because I added one too many sys.version_info branches, will try to figure out which one pushed it over the edge. Some of the remaining stubtest errors are false positives, fixing in python/mypy#19701 |
Uh oh!
There was an error while loading. Please reload this page.
This comment has been minimized.
This comment has been minimized.
AlexWaygood left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for pure-Python classes that are disjoint bases because they have __slots__, we should generally just add the __slots__ rather than adding the @disjoint_base decorator? That will help type checkers in other ways too (#8832). I highlighted a few here, but I think there are probably some more
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
JelleZijlstra commented Aug 20, 2025
Yes, I agree, but I'd rather not have to look at all of these classes manually. |
AlexWaygood commented Aug 21, 2025
yes, that's quite appealing, actually, from my perspective as a typeshed maintainer -- it would also be useful for deprecations, since we have an increasing number of Although that's actually quite convenient for us over at ty, because the deprecation notice is often also reflected in the docstring, and docstring-adder will add the version-specific docstrings to the two branches. |
…ypeshed/stdlib/ --fix
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Uh oh!
There was an error while loading. Please reload this page.
This comment has been minimized.
This comment has been minimized.
AlexWaygood left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM if you fix the TarInfo CI failure!
JelleZijlstra commented Aug 22, 2025
I think I need #14626 for CI to go green. I'll also wait for my mypy PR to be merged so I can pin stubtest to a commit from mypy master rather than a random one from my fork. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
JelleZijlstra commented Aug 24, 2025
Had to make some more tweaks to accommodate recent stubtest changes, but it's looking green now. I ignored one issue with |
Diff from mypy_primer, showing the effect of this PR on open source code: ibis (https://github.com/ibis-project/ibis) - ...typeshed_to_test/stdlib/builtins.pyi:115: note: "Any" defined here+ ...typeshed_to_test/stdlib/builtins.pyi:117: note: "Any" defined here- ...typeshed_to_test/stdlib/builtins.pyi:115: note: "__init__" of "object" defined here+ ...typeshed_to_test/stdlib/builtins.pyi:117: note: "__init__" of "object" defined here strawberry (https://github.com/strawberry-graphql/strawberry) - ...typeshed_to_test/stdlib/builtins.pyi:137: note: "__init_subclass__" of "object" defined here+ ...typeshed_to_test/stdlib/builtins.pyi:139: note: "__init_subclass__" of "object" defined here- ...typeshed_to_test/stdlib/builtins.pyi:137: note: "__init_subclass__" of "object" defined here+ ...typeshed_to_test/stdlib/builtins.pyi:139: note: "__init_subclass__" of "object" defined here prefect (https://github.com/PrefectHQ/prefect) - ...typeshed_to_test/stdlib/builtins.pyi:137: note: "__init_subclass__" of "object" defined here+ ...typeshed_to_test/stdlib/builtins.pyi:139: note: "__init_subclass__" of "object" defined here- ...typeshed_to_test/stdlib/builtins.pyi:137: note: "__init_subclass__" of "object" defined here+ ...typeshed_to_test/stdlib/builtins.pyi:139: note: "__init_subclass__" of "object" defined here- ...typeshed_to_test/stdlib/builtins.pyi:137: note: "__init_subclass__" of "object" defined here+ ...typeshed_to_test/stdlib/builtins.pyi:139: note: "__init_subclass__" of "object" defined here- ...typeshed_to_test/stdlib/builtins.pyi:137: note: "__init_subclass__" of "object" defined here+ ...typeshed_to_test/stdlib/builtins.pyi:139: note: "__init_subclass__" of "object" defined here- ...typeshed_to_test/stdlib/builtins.pyi:137: note: "__init_subclass__" of "object" defined here+ ...typeshed_to_test/stdlib/builtins.pyi:139: note: "__init_subclass__" of "object" defined here zulip (https://github.com/zulip/zulip) - ...typeshed_to_test/stdlib/builtins.pyi:115: note: "SubTest" defined here+ ...typeshed_to_test/stdlib/builtins.pyi:117: note: "SubTest" defined here discord.py (https://github.com/Rapptz/discord.py) - ...typeshed_to_test/stdlib/typing.pyi:1042: note: "update" of "TypedDict" defined here+ ...typeshed_to_test/stdlib/typing.pyi:1043: note: "update" of "TypedDict" defined here- discord/ext/commands/hybrid.py:834: error: Overlap between argument names and ** TypedDict items: "name", "with_app_command" [misc]+ discord/ext/commands/hybrid.py:834: error: Overlap between argument names and ** TypedDict items: "with_app_command", "name" [misc]- discord/ext/commands/hybrid.py:858: error: Overlap between argument names and ** TypedDict items: "name", "with_app_command" [misc]+ discord/ext/commands/hybrid.py:858: error: Overlap between argument names and ** TypedDict items: "with_app_command", "name" [misc]- discord/ext/commands/hybrid.py:883: error: Overlap between argument names and ** TypedDict items: "name", "with_app_command" [misc]+ discord/ext/commands/hybrid.py:883: error: Overlap between argument names and ** TypedDict items: "with_app_command", "name" [misc]- discord/ext/commands/hybrid.py:935: error: Overlap between argument names and ** TypedDict items: "name", "with_app_command" [misc]+ discord/ext/commands/hybrid.py:935: error: Overlap between argument names and ** TypedDict items: "with_app_command", "name" [misc]- discord/ext/commands/bot.py:290: error: Overlap between argument names and ** TypedDict items: "name", "with_app_command" [misc]+ discord/ext/commands/bot.py:290: error: Overlap between argument names and ** TypedDict items: "with_app_command", "name" [misc]- discord/ext/commands/bot.py:314: error: Overlap between argument names and ** TypedDict items: "name", "with_app_command" [misc]+ discord/ext/commands/bot.py:314: error: Overlap between argument names and ** TypedDict items: "with_app_command", "name" [misc] |
e8ba06f into python:mainUh oh!
There was an error while loading. Please reload this page.
tungol commented Aug 24, 2025
It's great to see all those allowlist entries go away |
No description provided.