Everything that isn't uv, ty, ruff is wrong and deprecated
Will you update the list for us, a month from now?
i doubt uv and ruff are going anywhere that quickly at least
Are you expected to run five Python type-checkers now?
171–180 of 220 posts
Re: Are you expected to run five Python type-checkers now?
#172Dynamically typed languages are going to decline with the rise of AI coding. Statically typed languages provide the determinism necessary to efficiently anchor probabalistic coding agents. You can throw as much type checking at dynamic languages after the fact, but youre just going to burn energy (and tokens) doing what another language gets 'for free'.
Or attach an LSP server with a type checker and require the model to produce strict strongly typed python code
Re: Are you expected to run five Python type-checkers now?
#173Earlier quoted context omitted.
Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.
> To the static typing folks: leave my dynamically typed languages alone Surely you understand that the push to add types to dynamically-typed languages comes from dynamic-typing folks, not from static-typing folks. People who are deeply into static typing have little incentive to consider e.g. Python, whose support for types is relatively weak, loosely-defined, and rarely-enforced compared to the statically-typed la…
> People who are deeply into static typing have little incentive
Except when their boss tell them to use Python, or they rely on one of Python libraries that their pet language couldn't provide via its powerful type system.
Re: Are you expected to run five Python type-checkers now?
#174Earlier quoted context omitted.
How so?
With writing code in english now, why have it use a slow weak language? ML still has a depth of libraries that can't be replicated easily but ML work is decreasing by the day with LLMs.
> With writing code in english now, why have it use a slow weak language?
Because the feedback loop of writing few lines of Python inside Jupyter cell is much shorter than with your currently favorite AI tool. It costs less too.
Re: Are you expected to run five Python type-checkers now?
#175If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?
Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.
God, I hope you never touch a production code base with real users. Strong, static typing has won. It is a must for serious software development. The time and money saved in stupid errors that are caught and avoided before the software even runs is enormous. For internal tools and one-off scripts, sure, go nuts with dynamic stuff, but there is no reason to use a dynamic language for code paths that actually make the business money. If you cannot specify precisely the type of every piece of data you touch and all the operations that can be performed on it, you're not doing software engineering, you're spitballing. And if you want to spitball, LLMs are here and they're great. You can type in a very loose description indeed and get properly typed Rust out the other end.
Re: Are you expected to run five Python type-checkers now?
#176Why anyone would still use mypy besides legacy infrastructure is beyond me. It is dog slow as well as being the laziest of all, not catching many mistakes. Unfortunately for Django apps switching to any alternative leads to the dreaded “wall of errors” issue. If anyone got to work this out in the past, I’d gladly take advices.
I use pyright with a 50k LOC Django REST API codebase. I haven't really had problems. From my pyproject.toml: django==4.2.30 djangorestframework==3.16.1 --- django-types==0.15.0 djangorestframework-types==0.8.0 pyright==1.1.390 My dj version is pretty old, but I'd assume things have only gotten better since v 4?
The django mypy plugin can inspect django models types, project settings and much more context.
Re: Are you expected to run five Python type-checkers now?
#177The whole type checking experience in python has disappointed me deeply and is seriously affecting my work. I see the appeal for type-checking and yeah it has caught many bugs. But the language is quickly running blindly to the worst of all worlds in regards to typing. 1. You have to exhaustively write types in many cases where they can be obviously inferred. 2. The type checking is just a lint step. i.e. we are stil…
Declaring types only where one wants to introduce a constraint would be nice, but unfortunately calls with obvious wrong types like "foo(5, {})" are a minority; in most cases types in a call depend on types of the calling function's parameters, and the type checker can only deduce unknown type from unconstrained type.
Moreover, the extremely dynamic execution and lack of compilation in Python means that determining in a lint step whether "there is no + operator for int and dictionary" is essentially impossible: if you find some __add__ or __radd__, you need to trust its declaration that it accepts certain types or not and hope it's still there at runtime; if you don't find it, it might exist at runtime when operator + is actually used.
A compiled and sufficiently static language, on the other hand, can inspect source code and libraries and reason about potentially infinite sets of definitions and prove that functions exist or don't exist.
Re: Are you expected to run five Python type-checkers now?
#178Earlier quoted context omitted.
Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.
It's not an all or nothing thing. I think types are particularly valuable for libraries. A library author using copious types really helps the downstream user to know "Ok, this function returns a dict(Foo, Bar)". But after that, it's a matter of preference if you want to add those types to your own code or not. Having the types in the libraries makes it a lot easier for your tools/IDEs to give good suggestions and ca…
I do think it is somewhat of an all or nothing thing. I can write dynamic languages, sure; I prefer having static types, but I have written a lot of dynamically typed code. However if I'm working in an editor with LSP integration, the experience is much worse when some things are missing types.
As an example, I may have a variable with types:
const something = somelibrary.getSomething();
const something = someWrapper(someLibrary.getSomething())
function doSomethingWith(something) {
...
}
doSomethingWith(someLibrary.getSomething()
I would much rather have a language where the compiler complains if some variable doesn't have a static type, than a language where I can accidentally leave something untyped. I don't understand which case I would want a variable or function to not have associated static type information.
Re: Are you expected to run five Python type-checkers now?
#179The fact that this article seems to honestly recommend people run 5 different type checkers on library test suits really reflects the tacked on feeling of Python typing.
It's ridiculous. They should have made it an explicit part of the language. The interpreter knows about types already, it's crazy that they couldn't just let the user make the types explicit rather than implicit, and have the interpreter enforce that.
The interpreter knows types at runtime, not at parse/compile time. The interpreter already does a lot of dynamic type checking. It has a much stricter type system than e.g JavaScript; JavaScript will pretty much always convert operands to produce some result (even if it's just NaN or the string "object Object"), while Python will often just give you a type error.
The interpreter doesn't know about static types.
I agree that they should've made typing more a proper part of the language and not left it in this weird half-defined state of "standard syntax and some standard typing imports but undefined semantics". But it's not just a matter of enforcing existing types.
Re: Are you expected to run five Python type-checkers now?
#180Why anyone would still use mypy besides legacy infrastructure is beyond me. It is dog slow as well as being the laziest of all, not catching many mistakes. Unfortunately for Django apps switching to any alternative leads to the dreaded “wall of errors” issue. If anyone got to work this out in the past, I’d gladly take advices.
We switched our very large Django monolith codebase over to ty — the trick for us was generating stubs for Django models and having tooling keep those stubs in sync with the actual models.
Went from type checking taking ~10 minutes in CI to now taking ~15 seconds and runs on pre-commit.
Absolute game changer, I think we spent $10k in claude credits and did the entire mypy -> ty refactor in about 3 weeks.