mypy type hints
No, type hints are, in my opinion, an abomination that has no business being part of the Python language :) May I at least add peewee's .pyi stubs to python/typeshed repository?  Anything you would like to do is totally fine by me, as the license for the software is permissive. I just do not want to merge anything into mainline that concerns type hinting. @coleifer I'm expecting you will make a deal with static typing fans more and more. I'm partially agree you can do nothing in orm itself and should not, but you should try to understand `static dynamic` fans. Its not about limiting dynamism or to make new java from python, people just want `user.(name/id/group)` in IDE, they are tired to go from view to model definition, to 'google' any functions signature, to debug typo mistakes in runtime. 

Go has no objects and generics, and any data structure should upcast value to `interface{}`, C is just too low-level. You should check out [typeorm](http://typeorm.io/) and [diesel](http://diesel.rs/), Dart. 
Static typing was stigmatized long time as a way to make compilable, fast languages like java, cpp. It has different purpose in dynamic languages now. > I'm expecting you will make a deal with static typing fans more and more.

No way. Python is a powerful dynamic language. If I want static typing or a strong type system I will use C or go...or hell, Cython. I enjoy coding in those languages, too, but if I'm using Python I'm going to play to it's strengths.

> IDE

Peewee's design goals are composability and consistency -- learn once, apply everywhere -- precisely so that peewee will "do what you expect" without needing to check the docs. @coleifer I'm not a strong proponent of Static Typing, but the type annotations are extremely useful when developing to help catch bugs. I debug enough Python at runtime, the more I can do to reduce that, the better.

Mypy is optional, you can choose to put annotations on things, for clarity. If the inclusion of these things only ever produces net gain, why not apply them. It's not an either-or camp. The degree to which you add Static Types is varying.

Surely you can see the point of view of why Type annotations may be extremely useful? And in no ways detracts from the power and flexibility of Python by its inclusion.
 Sorry to necro this thread but in my experience I've also noticed that type hints can also add a significant performance boost (sometimes >20%) since Cython can now use them for type inference. Granted, performance benefits aren't _guaranteed_ but they are likely. I see you have Cython support set up for PeeWee so it's entirely possible its performance could benefit from it. Hi @coleifer,

You've done a great job with this lib. With or without type hints, it's nice to use.

But if someday you change your mind about type hints, I believe it won't hurt. > No, type hints are, in my opinion, an abomination that has no business being part of the Python language :)

As a maintainer of typeshed, a big repository that is all about typing in Python, I think this is a perfectly valid opinion! I felt the same when I first learned about typing in Python. It shouldn't be something that library authors have to do, and it's optional by design. This issue was opened nearly 5 years ago. In that time I've had plenty of opportunities to see python's type hinting in the wild. I still believe that it misses the mark, offerning none of the iron-clad guarantees you get from a statically-typed language, while being injurious to Python's inherent dynamism, readability, and simplicity. Since this issue tends to attract drive-by comments of little value, I'm going to close discussion for now.

When I want static typing I reach for a statically-typed language. When I want expressiveness, simplicity and flexibility, I reach for Python.
Will you accept inline type hints for the peewee like
```
    # type: () -> None
```
as PR? 