Replies: 1 comment
|
This just seems like a bad idea, technically type checkers could special-case calling functions that were defined in the class scope within the class scope, but there's already a ton of special casing to make methods, Also the |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Please see this file: https://github.com/pypa/setuptools/pull/4099/files
Looking for guidance as to why the existing form is disallowed or discouraged. Is there a better way to handle this scenario than I did?
- Jaraco pypa/setuptools#4099 (comment)
Leaving it as-is leads to
Pyright:
Instance methods should take a "self" parameter [reportSelfClsParameterName]Pyright:
Argument of type "Self@AbstractSandbox" cannot be assigned to parameter "__name" of type "str" in function "getattr". "AbstractSandbox*" is incompatible with "str" [reportArgumentType]Mypy:
No overload variant of "getattr" matches argument types Module, "AbstractSandbox"Specifying the type for
name: str:Pyright:
Instance methods should take a "self" parameter [reportSelfClsParameterName]Mypy:
Self argument missing for a non-static method (or an invalid type for self) [misc]Changing the method to a
classmethod(with paramscls, name: strdoesn't work because I can't callAbstractSandbox._mk_dual_path_wrapperat the class-level.Using a
staticmethodleads to no type error (false-negative?) and the following error at runtime:All reactions