Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ty: A fast Python type checker and language server

github.com

Post reply on HN
Print view View original

261–270 of 296 posts

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

#261

Post by WD-42 »

bootsmann wrote: post #206
davedx wrote: post #179

Earlier quoted context omitted.

What might, possibly, redeem Python in my eyes as a potential language for making production applications (something that today, it is most certainly not) would be if the type checker worked across the broader ecosystem of common Python packages. For example, as my recent struggles showed, SQLAlchemy breaks `pyright` in all kinds of ways. Compared with how other 'dynamic' ORMs like Prisma interact with types, it's ju…

Only tangentially related but does anyone else here get very bothered when looking at the SQLAlchemy documentation? It seems so hard to find what kind of magic incantation you need to do in which order when trying to do a somewhat non-trivial query and I often just write the SQL I want and then tell chatGPT to rewrite it to SQLAlchemy operations but thats not really a sustainable solution.

Yes. It’s super opaque. SqlAlchemy is one of those libs I want to like but the docs just make it too difficult.

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

#263

Post by collinmanderson »

aleksanb wrote: post #20

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…

I also mentioned this up-thread, but https://pypi.org/project/django-types/ is compatible with pyright without plugins, so it should theoretically work with ty. It's not quite as good as the mypy-django plugin but it still catches a lot.

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

#264

Post by networked »

mapcars wrote: post #219
davedx wrote: post #189

Earlier quoted context omitted.

Ha. I just finished a huge rewrite at work from sync SQLAlchemy to async SQLAlchemy, because the async version uses a totally different API (core queries) to sync. So this implies if I want type checking I need to use a different ORM and start again? I love how Python makes me so much faster due to its dynamic nature! Move fast, break things!

I don't agree that dynamic nature makes things necessarily faster, if you compare Python to C or Java it is true, but if you compare to Typescript it is not. With a decent typing system and a good editor that makes use of it (and AI-assistants nowadays) the prototyping can actually be both faster and more stable.

I think davedx was being sarcastic. Python's dynamic nature cost them time.

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

#265

Post by ngoldbaum »

rrszynka wrote: post #202
ngoldbaum wrote: post #65

I gave away the “ty” project name on pypi to Astral a week or so ago. I wanted to use it for a joke a few years ago but this is a much better use for a two letter project name. They agreed to make a donation to the PSF to demonstrate their gratefulness.

nice! what was the planned joke?

Either something about beanie babies or something riffing on "thank you". Couldn't ever make up my mind then basically forgot about it.

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

#266

Post by davedx »

mapcars wrote: post #219
davedx wrote: post #189

Earlier quoted context omitted.

Ha. I just finished a huge rewrite at work from sync SQLAlchemy to async SQLAlchemy, because the async version uses a totally different API (core queries) to sync. So this implies if I want type checking I need to use a different ORM and start again? I love how Python makes me so much faster due to its dynamic nature! Move fast, break things!

I don't agree that dynamic nature makes things necessarily faster, if you compare Python to C or Java it is true, but if you compare to Typescript it is not. With a decent typing system and a good editor that makes use of it (and AI-assistants nowadays) the prototyping can actually be both faster and more stable.

Yes, I 100% agree. My career has been Java/C++ -> php/JavaScript -> typescript/python. Types are a godsend

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

#268

Post by bunderbunder »

networked wrote: post #252
dathinab wrote: post #83

Earlier quoted context omitted.

It's even worse (for python). TS might transpile to JS and can always be split into a js and type annotation file but is it's own language developed in tandem with the type check based on a holistisch approach to find how to type check then and then put it into the syntax and type checker. Thats not true for python at all. Python types where added as annotations to the language many years ago, but not in a holistic a…

Why do you say that duck typing is simplified structural typing? Its relationship with structural typing is on a different axis. Duck typing is its dynamic-typing counterpart. Python does support structural typing through protocols introduced in version 3.8. They are documented in https://typing.python.org/en/latest/spec/protocol.html . As a demo, here is part of https://www.typescriptlang.org/play/typescript/languag…

I'd go a step further and say that duck typing is more than just structural typing's dynamic counterpart. Because, again, that's confounding two different axes. Dynamic vs static describes when type checking happens and whether types are associated with names or with values. But it doesn't necessarily describe the definition of "type".

The real difference between structural typing and duck typing is that structural typing requires all of a type's declared members to be present for an object to be considered compatible. Duck typing only requires the members that are actually being accessed to be present.

This is definitely more common in dynamic languages, but I'm not aware of any particular reason why that kind of checking couldn't also be done statically.

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

#269

Post by pjmlp »

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.

It surely does, it is quite simple to correlate how many of those technologies are actually implemented in Python.

Pure Python that is.

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

#270

Post by johnfn »

globular-toast wrote: post #211
bootsmann wrote: post #206

Earlier quoted context omitted.

Only tangentially related but does anyone else here get very bothered when looking at the SQLAlchemy documentation? It seems so hard to find what kind of magic incantation you need to do in which order when trying to do a somewhat non-trivial query and I often just write the SQL I want and then tell chatGPT to rewrite it to SQLAlchemy operations but thats not really a sustainable solution.

Have you sat down and read the SQLAlchemy docs properly? It made a lot more sense to me once I'd set aside an hour or two to work through the Unified Tutorial.[0] I feel like these days people just want quick answers to do very specific things but that's a very inefficient way to learn something like SQLAlchemy. If you know the SQL you want it's just a matter of writing it in SQLAlchemy's query language which is quit…

> I feel like these days people just want quick answers to do very specific things but that's a very inefficient way to learn something like SQLAlchemy.

In defense of OP, a particular frustration I have with SQLAlchemy is that I understand SQL just fine, but the ways in which I translate my SQL knowledge into SQLAlchemy incantations is often pretty obscure. I think I deserve "quick answers to do very specific things" because I already have the exact form of the SQL solution in my head. That it then takes 20 minutes of digging through docs or ChatGPT is annoying.

Post reply on HN