Description

JukkaL

opened on Mar 21, 2015

Issue body actions

This are defined in the PEP 484 draft.

Reacted by Andrew

Activity

1. JukkaL

   added

   feature

   topic-pep-484

   on Mar 21, 2015
2. JukkaL

   changed the title [-]Support no_type_check and no_type_check_decorator[/-] [+]Support no_type_check_decorator[/+] on Mar 21, 2015
3. JukkaL commented on May 17, 2015

   

   JukkaL

   on May 17, 2015

   CollaboratorAuthor

   More actions

   This is now supported for functions but not for classes.
4. JukkaL

   changed the title [-]Support no_type_check_decorator[/-] [+]Support no_type_check_decorator for classes[/+] on May 17, 2015
5. JukkaL

   added

   priority-1-normal

   false-positivemypy gave an error on correct codemypy gave an error on correct code

   on May 17, 2018
6. lunixbochs commented on Mar 22, 2019

   

   lunixbochs

   on Mar 22, 2019

   More actions

   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.
7. gvanrossum commented on Mar 22, 2019

   

   gvanrossum

   on Mar 22, 2019

   Member

   More actions

   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?
8. gvanrossum

   changed the title [-]Support no_type_check_decorator for classes[/-] [+]Support @no_type_check for classes[/+] on Mar 22, 2019
9. gvanrossum commented on Mar 22, 2019

   

   gvanrossum

   on Mar 22, 2019

   Member

   More actions

   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.
10. lunixbochs commented on Jan 21, 2020

    

    lunixbochs

    on Jan 21, 2020

    More actions

    Can someone review my PR #6584?
11. AlexWaygood

    added

    topic-runtime-semanticsmypy doesn't model runtime semantics correctlymypy doesn't model runtime semantics correctly

    on Mar 27, 2022
12. hauntsaninja commented on Feb 4, 2024

    

    hauntsaninja

    on Feb 4, 2024

    Collaborator

    More actions

    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): ...

    Reacted by Jelle Zijlstra
13. jgarvin commented on Mar 12, 2024

    

    jgarvin

    on Mar 12, 2024

    More actions

    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,
        # ...
    )
    

Issue actions