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

191–200 of 296 posts

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

#191

Post by pjmlp »

davedx wrote: post #179
zanie wrote: post #28

:wave: Looks like you found the not-so-secret repository we're using to prepare for a broader announcement :) Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We're excited to get this in people's hands, but want to set the expectation that we still have a lot of work left to do before this is production ready. Sta…

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…

For me, until it gets a production quality JIT, or PyPy and GraalPY get more community love, it remains a scripting language for learning on how to program, automating OS and applications tasks.

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

#192

Post by pjmlp »

wpeterw wrote: post #184
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…

You mean Python is not a language for production applications ?

Only when performance doesn't matter, then it becomes a DSL for C and C++ libraries.

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

#193

Post by codr7 »

__MatrixMan__ wrote: post #183
bdzr wrote: post #169

Earlier quoted context omitted.

> I'm not proposing that we all just try harder to be altruistic, but rather that we craft some institution for rewarding people who have solved problems for many without encumbering those solutions with a monetization scheme. > I'm sure somebody has a better idea than mine, lets get creative. Every creative scheme I've seen someone try to come up with fails to do what charging money for a product can. Charge money f…

That's fine for software that can still scratch the itch after it has been turned into a product, but I think there's a lot of unexplored space outside that category. There's also a bunch of cases where adding tiers and payment flows blows the complexity budget and now what used to be a good idea is no longer worth it.

Yeah, I'm not that interested in selling stuff, it shifts the focus too much for me.

But I wouldn't mind being compensated for sharing what I create by those who find it useful.

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

#194

Post by surfingdino »

dathinab wrote: post #83
johnfn wrote: post #27

Earlier quoted context omitted.

In defense of mypy et al, Typescript had some of the greatest minds of our generation working for a decade+ on properly typing every insane form found in every random Javascript file. Microsoft has funded a team of great developers to hammer away at every obscure edge case imaginable. No other python checker can compare to the resources that TS had.

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…

What annoys me is that every programmers who wish their favourite language / feature was as popular as Python and they choose to implement it in Python to make Python "better". Python was created as a dynamically typed language. If you want a language with type checking, there are plenty of others available.

Rust devs in particular are on a bend to replace all other languages by stealth, which is both obviously visible and annoying, because they ignore what they don't know about the ecosystem they choose to target. As cool as some of the tools written for Python in Rust are (ruff, uv) they are not a replacement for Python. They don't even solve some annoying problems that we have workarounds for. Sometimes they create new ones. Case in point is uv, which offers custom Docker images. Hello? A package manager is not supposed to determine the base Docker image or Python version for the project. It's a tool, not even an essential one since we have others, so know your place. As much as I appreciate some of the performance gains I do not appreciate the false narratives spread by some Rust devs about the end of Python/JavaScript/Golang based on the fact that Rust allowed them to introduce faster build tools into other programming languages' build chains. Rust community is quickly evolving into the friends you are embarrassed to have, a bit like any JVM-based language that suddenly has a bunch of Enterprise Java guys showing up to a Kotlin party and telling everyone "we can be like Python too...".

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

#195

Post by lemontheme »

rtpg wrote: post #165
mil22 wrote: post #3

Earlier quoted context omitted.

Great, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast. https://github.com/microsoft/pyright

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…

If you haven’t checked it out already, basedpyright is pyright with all the arbitrarily carved out functionality put back in – plus some extra features that you may or may not find useful depending on how strict you like your typing.

Can’t recommend it enough

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

#196

Post by lemontheme »

insane_dreamer wrote: post #102
mil22 wrote: post #3

Earlier quoted context omitted.

Great, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast. https://github.com/microsoft/pyright

in my experience pyright is unable to infer many inherited object types (compared to PyCharm's type inference)

PyCharm definitely excels on more ‘dynamic’ code but the number of times I’ve pulled in code written by colleagues using PyCharm only to get a rainbow of type errors from Pyright is too damn high.

The PyCharm checker seems to miss really, really obvious things, e.g. allowing a call site to expect a string while the function returns bytes or none.

Maybe my colleagues just have it configured wrong but there’s several of them and the config isn’t shared.

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

#197

Post by lemontheme »

sakesun wrote: post #171
blibble wrote: post #110

prior to astral appearing, python's tooling has been beyond terrible, compared to say, Java's astral have now replaced the awful pip with the fantastic uv various awful linters with with the fantastic ruff and now hopefully replacing the terrible type checkers (e.g. mypy) with a good one! I hope they have the pypi backend on their list too, my kingdom for Maven Central in python!

Credit should also go to Rye project by Armin Ronacher.

Yeah, iirc he was the first to go ‘what if we had cargo for python?’

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

#198

Post by lemontheme »

no_time wrote: post #178

Awesome work. What is the business model for these astral tools? It’s a bit of a “waiting for the other shoe to drop” feeling after seeing the VC backing on the company page.

From what I’ve gathered (because I had similar concerns), the code is properly open source. In the very worst case, should there ever come a rug pull, it can be forked.

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

#199

Post by lukaslalinsky »

davedx wrote: post #180
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…

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.

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

#200

Post by fastball »

ZiiS wrote: post #112
zanie wrote: post #28

:wave: Looks like you found the not-so-secret repository we're using to prepare for a broader announcement :) Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We're excited to get this in people's hands, but want to set the expectation that we still have a lot of work left to do before this is production ready. Sta…

Pointlessmy anal; but 0.0.0a6 is very strongly indicative of the sixth alpha release. Pre-alpha are much better as .dev releases.

It is the sixth alpha release. They haven't yet released a stable version – this is their sixth alpha release before that.

What am I missing here?

Post reply on HN