Skip to content
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

Open
JukkaL opened this issue Mar 21, 2015 · 7 comments
Open

Support @no_type_check for classes #607

JukkaL opened this issue Mar 21, 2015 · 7 comments
Labels
false-positive mypy gave an error on correct code feature priority-1-normal topic-pep-484 topic-runtime-semantics mypy doesn't model runtime semantics correctly

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented Mar 21, 2015

This are defined in the PEP 484 draft.

@JukkaL JukkaL changed the title Support no_type_check and no_type_check_decorator Support no_type_check_decorator Mar 21, 2015
@JukkaL
Copy link
Collaborator Author

JukkaL commented May 17, 2015

This is now supported for functions but not for classes.

@JukkaL JukkaL changed the title Support no_type_check_decorator Support no_type_check_decorator for classes May 17, 2015
@JukkaL JukkaL added priority-1-normal false-positive mypy gave an error on correct code labels May 17, 2018
@lunixbochs
Copy link

The title here is incorrect, the @no_type_check decorator is working for functions but @no_type_check_decorator does not appear to be implemented.

@gvanrossum
Copy link
Member

Regarding the title, there seem to be two remaining issues.

  • @no_type_check isn't implemented for classes
  • @no_type_check_decorator isn't implemented at all

Note that the latter allows people to define their own decorators whose effect is equivalent to that of @no_type_check, i.e. this is a meta-level decorator.

AFAICT, #6584 will fix the first bullet but not the second. Perhaps we need to create a separate issue for the latter?

@gvanrossum gvanrossum changed the title Support no_type_check_decorator for classes Support @no_type_check for classes Mar 22, 2019
@gvanrossum
Copy link
Member

OK, changed the title to reflect that this issue (#607) is about the @no_type_check decorator as applied to classes, while the new #6583 is about the "meta" decorator, @no_type_check_decorator.

@lunixbochs
Copy link

Can someone review my PR #6584?

@hauntsaninja
Copy link
Collaborator

Linking a thread about what the semantics for no_type_check for classes should be: https://discuss.python.org/t/no-type-check-decorator/43119

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
Another possible semantics is basically replacing the class with class X(Any): ...

@jgarvin
Copy link

jgarvin commented Mar 12, 2024

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 inspect, not actually instantiated. I think there is a chicken and egg problem where people aren't going to demonstrate use cases as long as it doesn't work. In my case I abandoned the idea because I couldn't get any of the static type checkers to cooperate and instead used kwarg syntax and rely on the fact that in newer python versions kwarg order is preserved, e.g.

mystruct = gen.Struct(
    x=gen.Int32,
    y=gen.Float64,
    # ...
)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
false-positive mypy gave an error on correct code feature priority-1-normal topic-pep-484 topic-runtime-semantics mypy doesn't model runtime semantics correctly
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants