I really wish we had a ruff equivalent for python type checking, mypy is OK but it's really slow
There's pylyzer[0], but it's in the early stages.
Mypy 1.6
51–60 of 114 posts
Re: Mypy 1.6
#52Has 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 ( 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 genera…
At least today, my experience is that Pyright is faster, flags more issues, provides better error messages, and (alas for Mypy) has fewer bugs. I hope this will change over time as Mypy matures, but there you have it.
When using Pyright in large Django projects, it's helpful to add explicit type annotations in a number of places (like reverse relations in Models) but I've found this tends to improve the clarity of the resulting code anyway.
Re: Mypy 1.6
#53Earlier quoted context omitted.
> 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.
The point is that you don't need runtime type checking if you can trust your type checker.
There are few dynamic languages that go that far. Python isn't currently one of them; the runtime is still doing low-level type-compliance checks under the hood even if the static typing layer "knows" those checks are wasteful. At least in every compiler / runtime I'm familiar with for Python; maybe someone has built one that uses the types to generate faster code that's unsound if the static type assertions are violated.
Other dynamic-typed-and-also-static-typed languages do allow for this. Many Common Lisp compiler implementations, for example, respect things like the (the) special form (https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node106.html), which acts as a static type assertion that allows the compiler to actually throw away the runtime sanity-checking (at the cost of producing actual unsafe code if the constraints of the form are violated).
Re: Mypy 1.6
#54Earlier quoted context omitted.
> 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.
And yet machine code is basically untyped and fully dynamic. The world of computing is a strange place.
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.
Re: Mypy 1.6
#55Is 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
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.
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.
Re: Mypy 1.6
#56Earlier quoted context omitted.
And yet machine code is basically untyped and fully dynamic. The world of computing is a strange place.
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.
It's an implementation detail of popular architectures nowadays. It doesn't have to be like this.
Re: Mypy 1.6
#57Has 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 ( 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 genera…
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 runRe: Mypy 1.6
#58Has 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 ( 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 genera…
Pyright is much better.
It is much better written, much more correct, has fewer bugs, and it is the default in VSCode so less friction to set up.
In my experience it isn't hugely faster so I wouldn't say that is a big factor. The main benefit is that it is just very correct and has very few bugs (and when there are bugs they are fixed very quickly).
I would avoid Mypy if at all possible. I once tried to fix a bug in it and the codebase was very very hairy. Partly that's because it predates official type hinting support, and partly because it supports a load of hacks to allow incorrect types. Sometimes even the way you write the type affects how it is interpreted (e.g. `a # type: foo` is different to `a: foo`).
The only times I would choose Mypy is if you really need one of those plugins you mentioned, or if you are adding types to a legacy codebase and can't face seeing how bad it really is.
Re: Mypy 1.6
#59Has 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 ( 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 genera…
pyright and ruff are my new go to python tools, replacing mypy, pylint, isort and black.
So far the only thing that bothers me about pyright is that it can't infer the type of collections based on later insertions.
So in something like:
lst = []
lst.append(1)
I also program in Rust so I kinda expect this to work :P
I asked the maintainer about this and this is apparently by design, though mypy handles this correctly IIRC.
Re: Mypy 1.6
#60Earlier quoted context omitted.
> 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.
The point is that you don't need runtime type checking if you can trust your type checker.
If you're transpiling to Javascript, or running type-hinted Python, the runtime platform doesn't know about the type-checking you did at compile time.