Hacker News Reader

Comment by kodablah | Hacker News Reader

Fingers crossed this is/becomes extensible. Pyright and MyPy both suffer from lack of extensibility IMO (Pyright doesn't consider the use case and MyPy plugins come across as an afterthought with limited capabilities). There are many things that can be built on the back of type-checked AST.

View on HN

Charlie already said in a podcast (https://www.youtube.com/watch?v=XVwpL_cAvrw) that they are not looking to make it extensible. That it's considered a feature that type checking works interchangeably across tools and projects.

Ruff's linting and formatting is more likely to get plugin/extension support at some point in the future.

I wonder how they'll handle situations like Django, which don't seem expressible via stubs.

I love Django, but maybe Django should change more from their side? e.g. Django 6?

not specific to just your answer but why do people mention ruff?

Ruff is a linter which (intentionally) does close to no type checking.

So you pretty much have to pair it up with a type check to get any even just half way decent static code analysis.

Because ty was built out of the ruff code base, and is maintained by the same team, and the type checking abilities are intended to help ruff with linting rules in the future.

I’ve had this same thought. Ruff doesn’t support extensions / custom lint rules that I’m aware of, so maybe don’t get your hopes up.

Not supporting plugins for a type checker to me is a plus. It’s quite frustrating that some Python projects only typecheck if you have plugins. That is a major source of frustration.

I mean that kind of code exists; things like attrs are too magical otherwise

python packages that do a lot of metaprot can only be properly type checked if you replicate that metaprogramming at the type level. e.g. if dataclasses were not part of the standard library they would need a plug-in to be handled correctly.

Reply on news.ycombinator.com