-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Support @no_type_check for classes #607
Comments
This is now supported for functions but not for classes. |
The title here is incorrect, the |
Regarding the title, there seem to be two remaining issues.
Note that the latter allows people to define their own decorators whose effect is equivalent to that of AFAICT, #6584 will fix the first bullet but not the second. Perhaps we need to create a separate issue for the latter? |
Can someone review my PR #6584? |
Linking a thread about what the semantics for There is little evidence for any user demand for this feature, so this is overall unlikely to be implemented unless you, the reader, are willing to do it. Jelle mentions a possible semantics here: https://discuss.python.org/t/no-type-check-decorator/43119/34 |
FWIW re: user demand, I ran into wanting this feature which is why I'm subscribed. I wanted to be able to use the type annotation syntax for defining structs for generated code for IPC, but the types I would use wouldn't make sense to a normal type checker, and the class is only intended to be used for code generation via
|
This are defined in the PEP 484 draft.
The text was updated successfully, but these errors were encountered: