Ty: A fast Python type checker and language server • Hacker News Board

Re: Ty: A fast Python type checker and language server

#291

Post by bvrmn » Fri, May 09, 2025, 6:50 AM UTC

maleldil wrote: post #279

bvrmn wrote: post #134

Earlier quoted context omitted.

It's not mypy issue. Comparing to TS python typehints (spec wise) are a joke. It's started as bolted on adhoc solution and evolved quite chaotically. For example [1]. TS doesn't require a special decorator (sic!) to make your custom classes to be picked up by type checkers. Or how make a wrapper function with args and kwargs to pass through? [1]: https://docs.python.org/3/library/typing.html#typing.datacla...

The dataclass decorator isn't there to make the type checkers understand the class. Its main purpose is to automatically implement trivial methods like the constructor, equality, repr, etc. The type hints make this more convenient, but something similar already existed with attrs.

It's literally stated in the PEP: https://peps.python.org/pep-0681/

Also: https://github.com/python/mypy/blob/501a07b45af8e44eda665e53...

Also did you know mypy ignores typing of class decorators? You simply can't return a different type other than type[thisclass].

Re: Ty: A fast Python type checker and language server

#292

Post by taldo » Fri, May 09, 2025, 12:59 PM UTC

likeon wrote: post #235

ddorian43 wrote: post #172

Earlier quoted context omitted.

Use Pyright or basedpyright for now.

pylance is pyright

pylance is pyright + proprietary stuff on top, see https://docs.basedpyright.com/latest/ for a fork with some of pylance's features added.

Re: Ty: A fast Python type checker and language server

#293

Post by davedx » Fri, May 09, 2025, 6:17 PM UTC

lukaslalinsky wrote: post #199

davedx wrote: post #180

Earlier quoted context omitted.

Can mypy type check SQLAlchemy somehow? That's what caused me to give up on Python type checking recently

SQLAlchemy 2.x has direct support for mypy, it works out of the box, no longer needing mypy plugins. Many things in SQLAlchemy as are still dynamic and can't be type checked, but the native support works great where it can.

I’ll give that a try. Thanks

Re: Ty: A fast Python type checker and language server

#294

Post by tombolino » Fri, May 09, 2025, 10:40 PM UTC

Nab443 wrote: post #238

pjmlp wrote: post #218

Earlier quoted context omitted.

Maybe you should first investigate all the gimmicks they had to do, between amount of servers they had to ramp up burning needless budget, rewriting code into C and C++ libraries, Go or whatever else they ended up adding, before doing such statements. https://stackshare.io/instagram/instagram

Any other link to share about that? The stackshare url does not even mention anything related.

https://news.ycombinator.com/item?id=28610114

Re: Ty: A fast Python type checker and language server

#295

Post by rtpg » Fri, May 09, 2025, 11:42 PM UTC

mil22 wrote: post #287

rtpg wrote: post #165

Earlier quoted context omitted.

I don't get why so many people go to bat for pyright, my experience with it has been pretty miserable. Open enough instances of it and you're in OOM city. It works, but often gets confused... and of course the absolute audacity of MSFT to say "let's go over to pyright, and by the way we're going to carve up some stuff and put it into pylance instead", meaning that it's totally not within the actual spirit of open sou…

I tried all the type checkers available as of ~1 year ago, and Pyright worked the best for me. It's not perfect, but it's better than any of the pure Python checkers. Memory is cheap (unless you're buying it from Apple I guess...). Would I take a faster type checker with better memory footprint? Heck yes, assuming equal or superior functionality.

Memory ain’t that cheap on laptops in general! The bigger issue is less “pyright” and more “every tool out there being as heavy as pyright” + docker etc… but things are getting better IMO

Re: Ty: A fast Python type checker and language server

#296

Post by notatallshaw » Mon, May 12, 2025, 3:53 PM UTC

dathinab wrote: post #108

notatallshaw wrote: post #67

Earlier quoted context omitted.

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.

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.