4 ms·

Is anyone still using mypy, and if so why? I have replaced it by pyright [0] for a while now, and not looking back. It’s been a faster, more powerful replacemen

Is anyone still using mypy, and if so why? I have replaced it by pyright [0] for a while now, and not looking back. It’s been a faster, more powerful replacement with (in my case), zero downside. [0]: https://github.com/microsoft/pyright https://github.com/microsoft/pyright

ehsankia 3y ago
Is there any in depth comparison of mypy, pytype, pyright and pyre yet? They all seem to have slightly different approaches and features, but it's hard to decide which is best for the job.
- infecto 3y ago
  Not exactly what you are looking for but maybe useful to others. https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com...
- zem 3y ago
  we've written a little bit about what pytype does differently here: https://google.github.io/pytype/ 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.
keithasaurus 3y ago
mypy is essentially the reference implementation. pyright probably is better as a type checker, but, for the referential aspect alone, I suspect many libraries will continue targeting mypy. One potential benefit of mypy is that it comes with mypyc, a compiler that leverages mypy's evaluation of types. Since pyright and mypyc are not exactly equal, it makes sense to use mypy if you want to use mypyc.
aleksanb 3y ago
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 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.
- rand_r 3y ago
  Did you manage to get MyPy + Django to work together usefully? I tried the plugin you mentioned but it still seemed stymied by the dynamic nature of Django (reverse relations, etc), so I gave up on it. If it’s actually possible to live in typed nirvana with Django I’ll bang my head against the wall some more. We’re using Django 3.2 btw + FactoryBoy. Actually there’s a number of annoyingly dynamic Python libraries out there where methods are created dynamically that it feels a bit like playing whack-a-mole. Is the situation like TypeScript where you need a MyLibrary.types.ts for each library?
  - aleksanb 3y ago
    It's quite useful on ci, and as a `make mypy` can run before pushing up your code, but for interactive errors we all use pyright, which is a bit of a letdown because you don't get autocomplete for fields and models accessed through reverse relation managers etc, pyright doesn't know about them. Many packages ship types nowadays, so the type coverage isn't too bad for us right now. Here's our plugin setup in mypy.ini in case this helps (Django 4.2 + drf 3.14) [mypy] plugins = mypy_django_plugin.main, mypy_drf_plugin.main ignore_missing_imports = True follow_imports = silent no_implicit_optional = True warn_unused_ignores = True check_untyped_defs = True disallow_untyped_defs = True disallow_untyped_calls = True warn_unreachable = True strict_equality = True allow_redefinition = True show_error_codes = True mypy_path = stubs [mypy.plugins.django-stubs] django_settings_module = 'mycompany.settings' with packages: mypy==1.6.0 django-stubs==4.2.4 django-stubs-ext==4.2.2 djangorestframework-stubs==3.14.3 with this horror of a regex in make (because you'll get drowned in wrong type errors in all of the untype files, and errors get shown from imports even if you don't care about that imported file), add more file targets as necessary: FILES_TO_MYPY = $(shell ls mycompany/\*/validators.py mycompany/\*/services.py mycompany/\*/selectors.py mycompany/\*/managers.py | sort | uniq) # 1)We have to grep out django-manager-missing like this until the following bug # is fixed: https://github.com/python/mypy/issues/12987. # 2) We grep out the line of `Found 95 errors in 16 files (checked 83 source # files)` that now appears as we use follow-imports: silent, because there's a # bug where errors from imported modules are counted against the total even # though they aren't emitted. If any real errors appear we get them as a # separate line anyways. .PHONY: mypy mypy: @{ MYPY_FORCE_COLOR=${NOT_CI} $(VENV)/bin/mypy --config-file mypy.ini $(FILES_TO_MYPY) 2>&3 | grep -v 'django-manager-missing\|errors in'; } 3>&1 | tee $(HYRE_TESTS_OUTPUT_PATH)/mypy.stdout.txt This allows you to get proper errors for things like model = MyModel.objects.get() othermodel = model.othermodel_set.first() reveal_type(othermodel) # correctly revealed to note: Revealed type is "Union[mycompany.importpath.models.OtherModel None]" and even errors on typos like model = MyModel.objects.get() othermodel = model.ooooothermodel_set.first() # revealed as MyModel has no attribute ooooothermodel_set, perhaps you ment othermodel_set .
diarrhea 3y ago
I had started using mypy a couple years ago and simply never looked back at the decision. I perceived pyright as a Microsoft-specific tool, and waved it off, as mypy seemed the blessed and eventually converged-upon target. Turns out that’s wrong so far. Tons of people advocating for the latter. I quickly looked at the two repos. Pyright has 30 open issues. Mypy is at 2200. That is a simplistic metric, but an immense difference in any case.
- guappa 3y ago
  I guess mypy has 10x more users as well. People who use pyright use an IDE and they aren't likely to report a bug. https://pypistats.org/packages/mypy https://pypistats.org/packages/mypy https://pypistats.org/packages/pyright https://pypistats.org/packages/pyright
  - diarrhea 3y ago
    Ah okay, thanks for the context. The projects are quite close in terms of GitHub stars, 11k vs 16k.
    - guappa 3y ago
      Stars are meaningless. There are bots putting them at random to look like legit accounts and sell them to projects.
guappa 3y ago
apt install pyright E: Unable to locate package pyright apt install mypy mypy is already the newest version (1.6.0-1).
- 0xFF0123 3y ago
  https://pypi.org/project/pyright/ https://pypi.org/project/pyright/
- jpk 3y ago
  poetry add pyright :)
  - guappa 3y ago
    I tend to stick to things that are available in apt, so that my software is possible to distribute.

ehsankia 3y ago

Is there any in depth comparison of mypy, pytype, pyright and pyre yet? They all seem to have slightly different approaches and features, but it's hard to decide which is best for the job.

infecto 3y ago
Not exactly what you are looking for but maybe useful to others. https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com...
zem 3y ago
we've written a little bit about what pytype does differently here: https://google.github.io/pytype/ 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.

keithasaurus 3y ago

mypy is essentially the reference implementation. pyright probably is better as a type checker, but, for the referential aspect alone, I suspect many libraries will continue targeting mypy. One potential benefit of mypy is that it comes with mypyc, a compiler that leverages mypy's evaluation of types. Since pyright and mypyc are not exactly equal, it makes sense to use mypy if you want to use mypyc.

aleksanb 3y ago

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

rand_r 3y ago
Did you manage to get MyPy + Django to work together usefully? I tried the plugin you mentioned but it still seemed stymied by the dynamic nature of Django (reverse relations, etc), so I gave up on it. If it’s actually possible to live in typed nirvana with Django I’ll bang my head against the wall some more. We’re using Django 3.2 btw + FactoryBoy. Actually there’s a number of annoyingly dynamic Python libraries out there where methods are created dynamically that it feels a bit like playing whack-a-mole. Is the situation like TypeScript where you need a MyLibrary.types.ts for each library?
- aleksanb 3y ago
  It's quite useful on ci, and as a `make mypy` can run before pushing up your code, but for interactive errors we all use pyright, which is a bit of a letdown because you don't get autocomplete for fields and models accessed through reverse relation managers etc, pyright doesn't know about them. Many packages ship types nowadays, so the type coverage isn't too bad for us right now. Here's our plugin setup in mypy.ini in case this helps (Django 4.2 + drf 3.14) [mypy] plugins = mypy_django_plugin.main, mypy_drf_plugin.main ignore_missing_imports = True follow_imports = silent no_implicit_optional = True warn_unused_ignores = True check_untyped_defs = True disallow_untyped_defs = True disallow_untyped_calls = True warn_unreachable = True strict_equality = True allow_redefinition = True show_error_codes = True mypy_path = stubs [mypy.plugins.django-stubs] django_settings_module = 'mycompany.settings' with packages: mypy==1.6.0 django-stubs==4.2.4 django-stubs-ext==4.2.2 djangorestframework-stubs==3.14.3 with this horror of a regex in make (because you'll get drowned in wrong type errors in all of the untype files, and errors get shown from imports even if you don't care about that imported file), add more file targets as necessary: FILES_TO_MYPY = $(shell ls mycompany/\*/validators.py mycompany/\*/services.py mycompany/\*/selectors.py mycompany/\*/managers.py | sort | uniq) # 1)We have to grep out django-manager-missing like this until the following bug # is fixed: https://github.com/python/mypy/issues/12987. # 2) We grep out the line of `Found 95 errors in 16 files (checked 83 source # files)` that now appears as we use follow-imports: silent, because there's a # bug where errors from imported modules are counted against the total even # though they aren't emitted. If any real errors appear we get them as a # separate line anyways. .PHONY: mypy mypy: @{ MYPY_FORCE_COLOR=${NOT_CI} $(VENV)/bin/mypy --config-file mypy.ini $(FILES_TO_MYPY) 2>&3 | grep -v 'django-manager-missing\|errors in'; } 3>&1 | tee $(HYRE_TESTS_OUTPUT_PATH)/mypy.stdout.txt This allows you to get proper errors for things like model = MyModel.objects.get() othermodel = model.othermodel_set.first() reveal_type(othermodel) # correctly revealed to note: Revealed type is "Union[mycompany.importpath.models.OtherModel None]" and even errors on typos like model = MyModel.objects.get() othermodel = model.ooooothermodel_set.first() # revealed as MyModel has no attribute ooooothermodel_set, perhaps you ment othermodel_set .

diarrhea 3y ago

I had started using mypy a couple years ago and simply never looked back at the decision. I perceived pyright as a Microsoft-specific tool, and waved it off, as mypy seemed the blessed and eventually converged-upon target. Turns out that’s wrong so far. Tons of people advocating for the latter. I quickly looked at the two repos. Pyright has 30 open issues. Mypy is at 2200. That is a simplistic metric, but an immense difference in any case.

guappa 3y ago
I guess mypy has 10x more users as well. People who use pyright use an IDE and they aren't likely to report a bug. https://pypistats.org/packages/mypy https://pypistats.org/packages/mypy https://pypistats.org/packages/pyright https://pypistats.org/packages/pyright
- diarrhea 3y ago
  Ah okay, thanks for the context. The projects are quite close in terms of GitHub stars, 11k vs 16k.
  - guappa 3y ago
    Stars are meaningless. There are bots putting them at random to look like legit accounts and sell them to projects.

guappa 3y ago

apt install pyright E: Unable to locate package pyright apt install mypy mypy is already the newest version (1.6.0-1).

0xFF0123 3y ago
https://pypi.org/project/pyright/ https://pypi.org/project/pyright/
jpk 3y ago
poetry add pyright :)
- guappa 3y ago
  I tend to stick to things that are available in apt, so that my software is possible to distribute.