91–100 of 296 posts
Earlier quoted context omitted.
(ty developer here) This is an early preview of a pre-alpha tool, so I would expect a good chunk of those 3500 errors to be wrong at at this point :) Bug reports welcome!
Any rough estimates of how much faster you expect ty to be compared to mypy? I'd be super curious to know! I was also one of those people who, when first trying Ruff, assumed that it didn't work the first time I ran it because of how fast it executed!
It will certainly be slower than Ruff, just because multi-file type analysis more complex and less embarrassingly parallel than single-file linting.
The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods. I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck th…
Even Typescript is rewriting their compiler in Go. I think that the bottleneck is _actually_ the language sometimes. (And uv and ruff have basically proved that at this point)
which brings us to another python issue, python is quite bad at such huge refactoring even with type checkers
but yeah python is by far the slowest widely used language, and for some use cases you can side step it by placing most hot code in C++/Rust extension modules, (or don't care because you are much much more network latency bound) but a type checker probably doesn't belong into that category
Is this the same thing as Red Knot?
This will be similar to Typescript I assume? If so I can’t wait to use it!! I cant count how many times I’ve searched for “TS like in Python” since I’ve started working on Python codebase. TS is so awesome that I use it 100% on new projects. Ruff is also very good, but with this, large code base Python will be a breeze to work with
Also currently the Python IDE support (autocompletion, refactoring, etc.) in VSCode is provided by Pylance which is closed source, so this would provide an open source alternative to that.
Looks good but it has the same issues that i have with mypy. Packages that don't include the type hints blow-up my process. In mypy i've come to terms with strategically ignoring packages or finding a package of type hints. Mypy is runs cleanly on my project but I get >800 errors with TY, mostly things like: lint:unresolved-import: Cannot resolve imported module `pydantic` --> vartia/usr_id.py:4:6 | 2 | from typing i…
Curious why so many people want to implement type checkers for python? What problems are being solved that aren't covered already?
The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods. I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck th…
>The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. Nah, that's just part of the parade of excuses that comes out any time existing software solutions get smoked by a newcomer in performance, or when existing software gets more slow and bloated. Here's one of many examples: https://m.youtube.com/watch?v=GC-0tCy4P1U&pp=0gcJCdgAo7VqN5t...
not because they don't want to or because it's to slow
but because it's not really viable without fully executing module loading in a sandbox, which might seem viable until you realize that you still need to type check `__main__` modules etc. and that its a common trend in python to do configs by loading python modules and grabbing the module locals as keys of the config or loading some things might actually idk. initialize a GPU driver :sob: So it's kinda 100% guaranteed not possible to do fully correct type checking for all project :smh:
But also python is one of the slowest popular languages (and with a large margin to any not also "one of slowest" languages). Only by moving hot code into C++/Rust is it fast, which often is good enough, but a type checker is exactly this kind of software where this approach stops working.
Earlier quoted context omitted.
And in the process, they ended up creating an extremely powerful type system that ~nobody outside of that original team can (fully) understand.
IMHO they created type annotations, not a type system and how you use the type annotations to indicate a type system is inconsistent and incomplete (e.g. NoneType vs. None for inconsistency and a lot of mess related to mataclasses (e.g. Enum) and supporting type annotations for them for incomplete) the fact that even today something as fundamental as enums have issues with type checking _which are not just type check…
When it was released it might have been one of the easiest to use languages.
The focus on tooling and making the tooling fast has been sharp. Seeing people recommend using non-astral tooling seems nuts at this point.