django-stubs VS pytype

Pyright doesn't work with Django, as Django's so dynamic that it requires a plugin to infer all types correctly. Sadly, even mypy with plugins is a mess to get set up in vscode, especially if you want it to use the same config as you use for ci checks from the command line.

We use mypy + [django-stubs](https://github.com/typeddjango/django-stubs) (in a huge Django + drf project at day job) which includes a plugin for mypy allowing it to recognize all reverse relations and manager methods. Mypy is still really rough around the edges. The cli args are poorly documented, and how they correspond to declarations in a mypy.ini / pyproject.toml is mysterious. Match-statements still have bugs even a year after release. Exclusion of untyped / partially typed files and packages we've had to solve with grep filtering mypy's output for our whitelisted set of files, as it's been unable to separate properly between errors you care about (in your own codebase) and errors in others code (dependencies, untypable dynamic python packages etc).

The largest issue IMO is that mypy tried to adapt a java / OOP style way of type system onto python, instead of recognizing the language's real power within duck typing and passing structural types around. Typescript chose the right approach here, modelling javascript the way it is actually written, favoring structural over nominal typing, instead of the archaic and now left-behind way of Java-style OOP that has influenced mypy.

There was a recently accepted PEP which allowed for limited dataclass transforms, enough to cover the @attr.s usecase for both mypy and pyright, but nowhere near expressive enough to cover django's models and ORM sadly. It's probably impossible / undesirable to allow for such rich plugins, so i see the future for proper pluginless typing to be more akin to how pydantic / normal dataclasses solve typing, by starting with a specification of the types, deriving its runtime implementation, instead of plugins having to reverse the type representation of a custom DSL.

You can annotate the manager and get some typing help in the editor. And there’s django-stubs which helps a little when running mypy. It’s not as good as pycharm though.

https://github.com/typeddjango/django-stubs/tree/master

> Yes, there are type stubs for these libraries but they’re either forced to be more strict, preventing use of dynamism, or opt for being less strict but allowing you to use all the library features, at the cost of safety.

There are type stubs for Django that somewhat avoid these compromises: https://github.com/typeddjango/django-stubs

To be able to do this they have to use a Mypy plugin though. And even then it's still far from perfect.

Mypy together with this plug-in gives you typing for django. https://github.com/TypedDjango/django-stubs

Have you looked at stubs for Django?

it's open source! check out https://github.com/google/pytype and https://github.com/google/pytype/blob/main/docs/developers/t... for more on the multi-file runner

Pytype checks and infers types for your Python code - without requiring type annotations. Pytype can catch type errors in your Python code before you even run it.

Pyre from Meta, pyright from Microsoft and PyType from Google provide additional assistance. They can 'infer' types based on code flow and existing types within the code.

we've written a little bit about what pytype does differently here: https://google.github.io/pytype/

our main focus is to be able to work with unannotated and partially-annotated code, and treat it on par with fully annotated code.

So, I tried out pytype the other day, and it was a not a good experience. It doesn't support PEP 420 (implicit namespace packages), which means you have to litter __init__.py files everywhere, or it will create filename collisions. See https://github.com/google/pytype/issues/198 for more information. I've since started testing out pyre.

What is the smart money doing for type checking in Python? I've used mypy which seems to work well but is incredibly slow (3-4s to update linting after I change code). I've tried pylance type checking in VS Code, which seems to work well + fast but is less clear and comprehensive than mypy. I've also seen projects like pytype [1] and pyre [2] used by Google/Meta, but people say those tools don't really make sense to use unless you're an engineer for those companies.

Am just curious if mypy is really the best option right now?

[1] https://github.com/google/pytype

At Luma, we're using mypy to check nearly our entire code-base, including our Maya-related code, thanks to these latest changes. Fully adopting mypy (or an alternative like pytype) is no small feat, but working within a fully type-annotated code base with a type checker to enforce accuracy is like coding in a higher plane of existence: fewer bugs, easier code navigation, faster dev onboarding, easier refactoring, and dramatically increased confidence about every change. I wrote about some deeper insights in these posts.

Check out https://github.com/google/pytype

i work on https://github.com/google/pytype which is largely developed internally and then pushed to github every few days. the github commits are associated with the team's personal github accounts. pytype is not an "official google product" insofar as the open source version is presented as is without official google support, but it is "production code" in the sense that it is very much used extensively within google.

pytype dev here - thanks for the kind words :) whole-program analysis on unannotated or partially-annotated code is our particular focus, but there's surprisingly little dark PLT magic involved; in particular you don't need to be an academic type theory wizard to understand how it works. our developer docs[1] have more info, but at a high level we have an interpreter that virtually executes python bytecode, tracking types where the cpython interpreter would have tracked values.

it's worth exploring some of the other type checkers as well, since they make different tradeoffs - in particular, microsoft's pyright[2] (written in typescript!) can run incrementally within vscode, and tends to add new and experimentally proposed typing PEPs faster than we do.

[1] https://github.com/google/pytype/blob/main/docs/developers/i...