10 ms·

Mypy 1.6

167 points by hackandthink 3y ago

baq 3y ago
For the past year I've worked with a large JS/TS project undergoing a slow, gradual transformation into TS - before that, for the better part of past 10 years I worked on a Python 3 + some typing, lightly enforced by mypy. I must say I don't like JS, never have, likely never won't, but Typescript is a really pleasant language, even if JS underneath is more visible than I'd like. The mix of static analysis possible with TS vs added overhead of having to specify types (which can get very complex!) is just right. I welcome any and all efforts to make Python go this way - I'd be perfectly fine with transplanting TS type system as is.
- pjmlp 3y ago
  That is basically my sentiment towards C, while using C++. :)
- solarkraft 3y ago
  I find "dynamic during runtime + static during development" to be a highly potent combination because it largely prevents dumb programming mistakes and enables rich IDE hints while still allowing for enough magic to build beautiful interfaces. While they are usually a great benefit and easy enough to so, sometimes getting types just right can be more of an effort than it's worth - it's beautiful that in those cases you can still go "fuck it, I know what I'm doing". Best of both worlds, really.
  - brigadier132 3y ago
    > I find "dynamic during runtime + static during development" to be a highly potent combination Except you miss out on massive performance gains and your software runs 10x slower because of runtime type-checking. It's actually the worst of both worlds.
    - baq 3y ago
      And yet machine code is basically untyped and fully dynamic. The world of computing is a strange place.
      - civilitty 3y ago
        Machine code is type erased, not really untyped.
        nerdponx 3y ago
        If you squint, you could say the same about Python code that's been checked with Mypy.
      - shadowgovt 3y ago
        At the machine layer, the machine is doing symbol manipulation on bit patterns. Whether those symbols ultimately mean anything is entirely up to the eventual observer of the end result. The concept of "types" breaks down at this level much like the concept of "a dog" breaks down at the atomic level.
        baq 3y ago
        It's an implementation detail of popular architectures nowadays. It doesn't have to be like this. E.g. https://en.wikipedia.org/wiki/Tagged_architecture https://en.wikipedia.org/wiki/Tagged_architecture
    - nerdponx 3y ago
      The point is that you don't need runtime type checking if you can trust your type checker.
      - frou_dh 3y ago
        I have seen people point out that this confusing discussion can be avoided by accepting that types are purely a static property of terms (not only identifiers and literals) in source code, and that what many insist on calling dynamic types are tags, not types.
- networked 3y ago
  Do you know about Pyright? It is a Python type checker implemented in, and apparently influenced by, TypeScript. It is from Microsoft, so the influence is not that surprising. There was a recent HN submission about it: https://news.ycombinator.com/item?id=34222407 https://news.ycombinator.com/item?id=34222407. I use Pyright as my primary type checker and mypy as a secondary. (For example, Pyright won't run in Termux on my phone. I could likely fix this, but mypy just installs with pipx.) There is a document comparing Pyright and mypy in the Pyright repository: https://github.com/microsoft/pyright/blob/b09f35889a9cc9b262467097c9b027b6c3939870/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/b09f35889a9cc9b262....
  - VeejayRampay 3y ago
    I think by design, pyright works on single files, not whole codebases, unless you add some scripting on top of it
- mjr00 3y ago
  Python's typing ecosystem has come leaps and bounds, quickly. About 5 years ago I had to do an evaluation of Python+mypy and found that while mypy was a great idea, support by major libraries was abysmal and mypy itself was immature, so it wasn't suitable for real use. 2 years later, I took another look and the ecosystem had evolved massively, most libraries I cared about had type annotations added, PyCharm/VSCode had added support for type checking in the IDE, etc. These days all of my use of Python is with type annotations that are validated by mypy as part of CI. It's very rare that I run into a Python library that doesn't have type annotations available. It's massively improved the stability of the Python code I'm working on. One indirect side effect is that static typing actively discourages people from poor design patterns such as **kwargs or passing around dicts/dataframes of data, since there's an obvious downside to doing so now.
  - bjornasm 3y ago
    I agree with avoiding *kwargs, but I wonder what we should do rather than to pass around dataframes if we have a program that works with dataframes? I get that there is a downside as the actual types are hidden inside the dataframes, but I am unsure if the tradeoff is worth it by unpacking the dataframe into arrays or objects for every function call and return, if the functions require them to be dataframes?
    - sgarland 3y ago
      You can define nested types for args and return values: def foo(bar: dict[int, dict[int, str]]) -> list[tuple[str]] In older (< 3.10 ?) versions you have to import the classes from the typing module, but other than that it’s the same. You can also define types with the Generic class if you’d rather. With live checks while you write, it’s pretty easy to do this as you go.
    - mjr00 3y ago
      Sadly I haven't found any good ways to strongly type dataframes, so my solution is mainly cultural: just make people aware that they shouldn't use dataframes unless it makes sense, as opposed to Python codebases where dataframes are the default data type that gets passed around. I've tried to limit dataframe usage only to things like reading data from CSVs, then converting them to typed dataclasses before further processing. It also depends on your use case. pandas is obviously very flexible and easy to use, so it might be worth the tradeoff to keep using it if your main use case is interactive Jupyter notebooks run by data scientists, or dealing with highly variable input data. But most of my Python is backend data pipelines that work on predictable input data, where reliability is important, so I default to dataclasses, only using pandas in rare situations with a lot of validation code surrounding it.
- deleted 3y ago
  [deleted]
totoglazer 3y ago
The continued growth and maturity of typing and LLMs like GitHub copilot finally make IDEs powerful for python. Excited about the future of the language.
imjonse 3y ago
In the age of most projects having animated websites, videos on the homepages, ads for courses and maybe an online conference for launching a new version, I find this use of 2006-era blogspot strangely comforting.
- kunley 3y ago
  It is a pity I can't upvote you more than once ;)
- thejosh 3y ago
  Also has what the product actually IS in the header and everything! "Updates about mypy, an optional static type checker for Python"
  - Twirrim 3y ago
    But why would you want to learn that without having to wade through dozens of pages? Crazy talk.
- coding123 3y ago
  no idea how blogspot has survived this long
  - ronsor 3y ago
    Google can't kill it since they forgot about it
- deleted 3y ago
  [deleted]
syntaxing 3y ago
I work on a monorepo and MyPy and Flake8 was such a PITA at first but after you use it for a while, you really see the value of type checking. Makes unit testing better and the code more robust in general. MyPy is seriously a great tool, especially with pydoc enforcements.
- softirq 3y ago
  At that point, why not just use Go? It's designed to feel dynamic, provides concurrency primitives out of the box, and it's orders of magnitude faster for most tasks.
  - pjmlp 3y ago
    It is a downgrade in language features, there is always PyPy.
    - softirq 3y ago
      If you don't consider static type and built in concurrency primitives features then ok, at what point does nice to have features outweigh performance gains and the robustness of static typing that directly impacts the quality of the end user experience and the readability of the code to other developers?
      - pjmlp 3y ago
        Python has built in concurrency support, stuff like Mypy and IDE tooling make up for the dynamic typing. And if that isn't enough, the answer is OCaml, F#, D, C#, Java, Scala, Haskell, Kotlin, C++,... definitely not going from horse to donkey in language features.
      - orangecat 3y ago
        readability of the code to other developers I disagree that Go's insistence on verbosity improves readability. Each individual line may simpler, but the larger purpose of the code is obscured in all the "if err != nil" weeds. My unpopular opinion is that Dart should get a lot more attention. Strong typing with null-safety, compiles to native, batteries included, and nearly as expressive as Python.
KolmogorovComp 3y ago
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.
_fdsfs12123 3y ago
Has anyone had to choose between Mypy and Pyright? Which is "better"? A couple years ago I was in charge of choosing between the two, and I somewhat flippantly chose Pyright because it felt a lot faster (<5 second to do 30k lines) and had an easy integration with the editors people use at work (Pylance, coc-pyright). Later, I realized that some popular libraries we use (django, numpy) have dedicated plugins for Mypy that you can't use with Pyright. So you have to look for Pyright-friendly type stubs or roll your own. I've generally liked Pyright (as a side note, they have super responsive maintainers - ask a question on their GH, and they usually answer within a few hours), but I've been wondering if I am missing out with Mypy.
- maximilianroos 3y ago
  For those using mypy and wishing it were a bit faster — dmypy is really good. I often leave this running, so I can see live errors on every save: watchexec -rc -e py -- dmypy run
- rhaps0dy 3y ago
  Pyright is great, and IME does more inference than Mypy and flags more errors. Mypy is catching up on speed though! Can't say I've tried any plugins.
- globular-toast 3y ago
  For Django there is django-types, a fork of django-stubs that works without the mypy plugin. There might be similar for numpy.
- kps 3y ago
  I don't touch Python much, so last time I wrote something, I used mypy and pyright and pylint and ruff.
- strokirk 3y ago
  Pyright doesn’t really support a lot of big libraries, like Django, so if you want to use them you’re out of luck.
- kelsolaar 3y ago
tyingq 3y ago
I want to like type hinted python, but there's always some corner case. Which is fine if I'm writing the rules, but there are teams that force things like "no adding ignore/disable for things you can't figure out".
bloopernova 3y ago
Somewhat offtopic, does anyone have a link to a page that describes which extensions/tools I should be using with VSCode to author Python code? Edited to add: when you read various recommendations, they're all discrete and don't have the overall context. e.g. I installed the VSCode suggested extensions, but then read a comment that I should really be using Ruff. OK, that's good, but if I have extensions X, Y, and Z, should I add extensions A, B, and C?
- jimmydoe 3y ago
  the default extension is good enough to begin with. as you are adding more to your project (e.g. black/isort/django), you can naturally find more extensions.
  - chpatrick 3y ago
    One nuisance I found is that it's hard to get the VSCode Pyright to apply the same rules as the command-line one, which is very annoying when your IDE says the code is okay but it fails on CI. Not sure if that's fixed yet.
- gen220 3y ago
  These pages are naturally out of date from the moment they're written. Caveats aside, I use pyright, ruff and black (although ruff will probably one day consume `black`, entirely) – that's it. `ruff` centralizes a lot of the linter/fixer ecosystem (isort, autoflake, pylint and more). `pyright` is for GoToDefinition and type-checking. `black` is for sanity-checking what `ruff` spits out, and should hopefully not be necessary (for me) as a standalone package at some point in the near future. Ruff is not 1.0 yet, so I wouldn't use it at work – but I use it in all my own things.
  - bloopernova 3y ago
    Thank you, that description of each extension and how they work together is exactly what I was looking for. I appreciate you, internet person.
VeejayRampay 3y ago
I really wish we had a ruff equivalent for python type checking, mypy is OK but it's really slow
- maleldil 3y ago
  There's pylyzer[0], but it's in the early stages. [0] https://github.com/mtshiba/pylyzer https://github.com/mtshiba/pylyzer
- networked 3y ago
  Pyre, written in OCaml, is the closest thing that's stable. It has been discussed on HN a couple of times. Here is the 2021 discussion: https://news.ycombinator.com/item?id=27107647 https://news.ycombinator.com/item?id=27107647. Note that Pyre does not support Windows (https://github.com/facebook/pyre-check/issues/554 https://github.com/facebook/pyre-check/issues/554) and only provides wheels for x86_64 Linux and macOS (https://pypi.org/project/pyre-check/0.9.18/#files https://pypi.org/project/pyre-check/0.9.18/#files). While I don't use Windows, it makes me reluctant to adopt it. First, I want Windows users to be able to contribute to my projects that work on Windows. Mypy and (predictably) Pyright won't create an obstacle for Windows users. Second, the limited number of platforms makes Pyre seem a little internal-toolish. It may still be worth it. As of today, actually, one of my projects has a Pyre branch. I want to see what it is like developing with it.
  - VeejayRampay 3y ago
    there's something a bit strange with pyre though, I feel like it makes it too difficult to check types in a subdirectory (like you have to provide a configuration or something) it works well and fast for a whole codebase though
cbb330 3y ago
I have 90 PRs to Mypy configured repos this year, across 10+ python repos which are a mix of services and background jobs. All of them have some mix of pyright/jedi+ruff+black. I have implemented these tools either via CI or in my ide like experience in NVim. TLDR; BE WARNED. this basket of bandaids is NOT a replacement for a strongly typed language. I would NOT recommend Python to teams or for services. No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language. This collection of bandaids is complex to maintain, upgrade, standardize, and has infinite edge cases where type annotation errors are just wrong. The worst part about this basket is that you get all of the above features for free and are REQUIRED with go via gopls and gofmt. Gopls "is the official Go language server developed by the Go team." good luck achieving parity of this in python. If you implement a service/app/anything production, use anything but a dynamically typed language like python.
- linkdd 3y ago
  > No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language. Ah yes, because Python was never used in production ever, not at Google, not at Dropbox, not ever. The "static typing above all else" cargo cult is getting ridiculous.
  - cbb330 3y ago
    It doesn't take an expert to notice that enforced types make a language more reliable in production, easier to debug, and faster to refactor. You should be horrified by Dropbox's blog post on python in production: https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python https://dropbox.tech/application/our-journey-to-type-checkin.... because this problem only existed and required $Ms of dollars to fix (even hiring the core team behind Mypy) because Python is being used instead of a typed language.
    - linkdd 3y ago
      I'm not saying that static typing has no value, it certainly does. But rejecting all dynamically typed language is a poor shortcut to take. Python, Ruby, Javascript, and others have a lot of success stories.

167 points by hackandthink 3y ago

baq 3y ago

For the past year I've worked with a large JS/TS project undergoing a slow, gradual transformation into TS - before that, for the better part of past 10 years I worked on a Python 3 + some typing, lightly enforced by mypy. I must say I don't like JS, never have, likely never won't, but Typescript is a really pleasant language, even if JS underneath is more visible than I'd like. The mix of static analysis possible with TS vs added overhead of having to specify types (which can get very complex!) is just right. I welcome any and all efforts to make Python go this way - I'd be perfectly fine with transplanting TS type system as is.

pjmlp 3y ago
That is basically my sentiment towards C, while using C++. :)
solarkraft 3y ago
I find "dynamic during runtime + static during development" to be a highly potent combination because it largely prevents dumb programming mistakes and enables rich IDE hints while still allowing for enough magic to build beautiful interfaces. While they are usually a great benefit and easy enough to so, sometimes getting types just right can be more of an effort than it's worth - it's beautiful that in those cases you can still go "fuck it, I know what I'm doing". Best of both worlds, really.
- brigadier132 3y ago
  > I find "dynamic during runtime + static during development" to be a highly potent combination Except you miss out on massive performance gains and your software runs 10x slower because of runtime type-checking. It's actually the worst of both worlds.
  - baq 3y ago
    And yet machine code is basically untyped and fully dynamic. The world of computing is a strange place.
    - civilitty 3y ago
      Machine code is type erased, not really untyped.
      - nerdponx 3y ago
        If you squint, you could say the same about Python code that's been checked with Mypy.
    - shadowgovt 3y ago
      At the machine layer, the machine is doing symbol manipulation on bit patterns. Whether those symbols ultimately mean anything is entirely up to the eventual observer of the end result. The concept of "types" breaks down at this level much like the concept of "a dog" breaks down at the atomic level.
      - baq 3y ago
        It's an implementation detail of popular architectures nowadays. It doesn't have to be like this. E.g. https://en.wikipedia.org/wiki/Tagged_architecture https://en.wikipedia.org/wiki/Tagged_architecture
  - nerdponx 3y ago
    The point is that you don't need runtime type checking if you can trust your type checker.
    - frou_dh 3y ago
      I have seen people point out that this confusing discussion can be avoided by accepting that types are purely a static property of terms (not only identifiers and literals) in source code, and that what many insist on calling dynamic types are tags, not types.
networked 3y ago
Do you know about Pyright? It is a Python type checker implemented in, and apparently influenced by, TypeScript. It is from Microsoft, so the influence is not that surprising. There was a recent HN submission about it: https://news.ycombinator.com/item?id=34222407 https://news.ycombinator.com/item?id=34222407. I use Pyright as my primary type checker and mypy as a secondary. (For example, Pyright won't run in Termux on my phone. I could likely fix this, but mypy just installs with pipx.) There is a document comparing Pyright and mypy in the Pyright repository: https://github.com/microsoft/pyright/blob/b09f35889a9cc9b262467097c9b027b6c3939870/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/b09f35889a9cc9b262....
- VeejayRampay 3y ago
  I think by design, pyright works on single files, not whole codebases, unless you add some scripting on top of it
mjr00 3y ago
Python's typing ecosystem has come leaps and bounds, quickly. About 5 years ago I had to do an evaluation of Python+mypy and found that while mypy was a great idea, support by major libraries was abysmal and mypy itself was immature, so it wasn't suitable for real use. 2 years later, I took another look and the ecosystem had evolved massively, most libraries I cared about had type annotations added, PyCharm/VSCode had added support for type checking in the IDE, etc. These days all of my use of Python is with type annotations that are validated by mypy as part of CI. It's very rare that I run into a Python library that doesn't have type annotations available. It's massively improved the stability of the Python code I'm working on. One indirect side effect is that static typing actively discourages people from poor design patterns such as **kwargs or passing around dicts/dataframes of data, since there's an obvious downside to doing so now.
- bjornasm 3y ago
  I agree with avoiding *kwargs, but I wonder what we should do rather than to pass around dataframes if we have a program that works with dataframes? I get that there is a downside as the actual types are hidden inside the dataframes, but I am unsure if the tradeoff is worth it by unpacking the dataframe into arrays or objects for every function call and return, if the functions require them to be dataframes?
  - sgarland 3y ago
    You can define nested types for args and return values: def foo(bar: dict[int, dict[int, str]]) -> list[tuple[str]] In older (< 3.10 ?) versions you have to import the classes from the typing module, but other than that it’s the same. You can also define types with the Generic class if you’d rather. With live checks while you write, it’s pretty easy to do this as you go.
  - mjr00 3y ago
    Sadly I haven't found any good ways to strongly type dataframes, so my solution is mainly cultural: just make people aware that they shouldn't use dataframes unless it makes sense, as opposed to Python codebases where dataframes are the default data type that gets passed around. I've tried to limit dataframe usage only to things like reading data from CSVs, then converting them to typed dataclasses before further processing. It also depends on your use case. pandas is obviously very flexible and easy to use, so it might be worth the tradeoff to keep using it if your main use case is interactive Jupyter notebooks run by data scientists, or dealing with highly variable input data. But most of my Python is backend data pipelines that work on predictable input data, where reliability is important, so I default to dataclasses, only using pandas in rare situations with a lot of validation code surrounding it.
deleted 3y ago
[deleted]

totoglazer 3y ago

The continued growth and maturity of typing and LLMs like GitHub copilot finally make IDEs powerful for python. Excited about the future of the language.

imjonse 3y ago

In the age of most projects having animated websites, videos on the homepages, ads for courses and maybe an online conference for launching a new version, I find this use of 2006-era blogspot strangely comforting.

kunley 3y ago
It is a pity I can't upvote you more than once ;)
thejosh 3y ago
Also has what the product actually IS in the header and everything! "Updates about mypy, an optional static type checker for Python"
- Twirrim 3y ago
  But why would you want to learn that without having to wade through dozens of pages? Crazy talk.
coding123 3y ago
no idea how blogspot has survived this long
- ronsor 3y ago
  Google can't kill it since they forgot about it
deleted 3y ago
[deleted]

syntaxing 3y ago

I work on a monorepo and MyPy and Flake8 was such a PITA at first but after you use it for a while, you really see the value of type checking. Makes unit testing better and the code more robust in general. MyPy is seriously a great tool, especially with pydoc enforcements.

softirq 3y ago
At that point, why not just use Go? It's designed to feel dynamic, provides concurrency primitives out of the box, and it's orders of magnitude faster for most tasks.
- pjmlp 3y ago
  It is a downgrade in language features, there is always PyPy.
  - softirq 3y ago
    If you don't consider static type and built in concurrency primitives features then ok, at what point does nice to have features outweigh performance gains and the robustness of static typing that directly impacts the quality of the end user experience and the readability of the code to other developers?
    - pjmlp 3y ago
      Python has built in concurrency support, stuff like Mypy and IDE tooling make up for the dynamic typing. And if that isn't enough, the answer is OCaml, F#, D, C#, Java, Scala, Haskell, Kotlin, C++,... definitely not going from horse to donkey in language features.
    - orangecat 3y ago
      readability of the code to other developers I disagree that Go's insistence on verbosity improves readability. Each individual line may simpler, but the larger purpose of the code is obscured in all the "if err != nil" weeds. My unpopular opinion is that Dart should get a lot more attention. Strong typing with null-safety, compiles to native, batteries included, and nearly as expressive as Python.

KolmogorovComp 3y ago

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.

_fdsfs12123 3y ago

Has anyone had to choose between Mypy and Pyright? Which is "better"? A couple years ago I was in charge of choosing between the two, and I somewhat flippantly chose Pyright because it felt a lot faster (<5 second to do 30k lines) and had an easy integration with the editors people use at work (Pylance, coc-pyright). Later, I realized that some popular libraries we use (django, numpy) have dedicated plugins for Mypy that you can't use with Pyright. So you have to look for Pyright-friendly type stubs or roll your own. I've generally liked Pyright (as a side note, they have super responsive maintainers - ask a question on their GH, and they usually answer within a few hours), but I've been wondering if I am missing out with Mypy.

maximilianroos 3y ago
For those using mypy and wishing it were a bit faster — dmypy is really good. I often leave this running, so I can see live errors on every save: watchexec -rc -e py -- dmypy run
rhaps0dy 3y ago
Pyright is great, and IME does more inference than Mypy and flags more errors. Mypy is catching up on speed though! Can't say I've tried any plugins.
globular-toast 3y ago
For Django there is django-types, a fork of django-stubs that works without the mypy plugin. There might be similar for numpy.
kps 3y ago
I don't touch Python much, so last time I wrote something, I used mypy and pyright and pylint and ruff.
strokirk 3y ago
Pyright doesn’t really support a lot of big libraries, like Django, so if you want to use them you’re out of luck.
kelsolaar 3y ago

tyingq 3y ago

I want to like type hinted python, but there's always some corner case. Which is fine if I'm writing the rules, but there are teams that force things like "no adding ignore/disable for things you can't figure out".

bloopernova 3y ago

Somewhat offtopic, does anyone have a link to a page that describes which extensions/tools I should be using with VSCode to author Python code? Edited to add: when you read various recommendations, they're all discrete and don't have the overall context. e.g. I installed the VSCode suggested extensions, but then read a comment that I should really be using Ruff. OK, that's good, but if I have extensions X, Y, and Z, should I add extensions A, B, and C?

jimmydoe 3y ago
the default extension is good enough to begin with. as you are adding more to your project (e.g. black/isort/django), you can naturally find more extensions.
- chpatrick 3y ago
  One nuisance I found is that it's hard to get the VSCode Pyright to apply the same rules as the command-line one, which is very annoying when your IDE says the code is okay but it fails on CI. Not sure if that's fixed yet.
gen220 3y ago
These pages are naturally out of date from the moment they're written. Caveats aside, I use pyright, ruff and black (although ruff will probably one day consume `black`, entirely) – that's it. `ruff` centralizes a lot of the linter/fixer ecosystem (isort, autoflake, pylint and more). `pyright` is for GoToDefinition and type-checking. `black` is for sanity-checking what `ruff` spits out, and should hopefully not be necessary (for me) as a standalone package at some point in the near future. Ruff is not 1.0 yet, so I wouldn't use it at work – but I use it in all my own things.
- bloopernova 3y ago
  Thank you, that description of each extension and how they work together is exactly what I was looking for. I appreciate you, internet person.

VeejayRampay 3y ago

I really wish we had a ruff equivalent for python type checking, mypy is OK but it's really slow

maleldil 3y ago
There's pylyzer[0], but it's in the early stages. [0] https://github.com/mtshiba/pylyzer https://github.com/mtshiba/pylyzer
networked 3y ago
Pyre, written in OCaml, is the closest thing that's stable. It has been discussed on HN a couple of times. Here is the 2021 discussion: https://news.ycombinator.com/item?id=27107647 https://news.ycombinator.com/item?id=27107647. Note that Pyre does not support Windows (https://github.com/facebook/pyre-check/issues/554 https://github.com/facebook/pyre-check/issues/554) and only provides wheels for x86_64 Linux and macOS (https://pypi.org/project/pyre-check/0.9.18/#files https://pypi.org/project/pyre-check/0.9.18/#files). While I don't use Windows, it makes me reluctant to adopt it. First, I want Windows users to be able to contribute to my projects that work on Windows. Mypy and (predictably) Pyright won't create an obstacle for Windows users. Second, the limited number of platforms makes Pyre seem a little internal-toolish. It may still be worth it. As of today, actually, one of my projects has a Pyre branch. I want to see what it is like developing with it.
- VeejayRampay 3y ago
  there's something a bit strange with pyre though, I feel like it makes it too difficult to check types in a subdirectory (like you have to provide a configuration or something) it works well and fast for a whole codebase though

cbb330 3y ago

I have 90 PRs to Mypy configured repos this year, across 10+ python repos which are a mix of services and background jobs. All of them have some mix of pyright/jedi+ruff+black. I have implemented these tools either via CI or in my ide like experience in NVim. TLDR; BE WARNED. this basket of bandaids is NOT a replacement for a strongly typed language. I would NOT recommend Python to teams or for services. No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language. This collection of bandaids is complex to maintain, upgrade, standardize, and has infinite edge cases where type annotation errors are just wrong. The worst part about this basket is that you get all of the above features for free and are REQUIRED with go via gopls and gofmt. Gopls "is the official Go language server developed by the Go team." good luck achieving parity of this in python. If you implement a service/app/anything production, use anything but a dynamically typed language like python.

linkdd 3y ago
> No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language. Ah yes, because Python was never used in production ever, not at Google, not at Dropbox, not ever. The "static typing above all else" cargo cult is getting ridiculous.
- cbb330 3y ago
  It doesn't take an expert to notice that enforced types make a language more reliable in production, easier to debug, and faster to refactor. You should be horrified by Dropbox's blog post on python in production: https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python https://dropbox.tech/application/our-journey-to-type-checkin.... because this problem only existed and required $Ms of dollars to fix (even hiring the core team behind Mypy) because Python is being used instead of a typed language.
  - linkdd 3y ago
    I'm not saying that static typing has no value, it certainly does. But rejecting all dynamically typed language is a poor shortcut to take. Python, Ruby, Javascript, and others have a lot of success stories.