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

241–250 of 296 posts

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

#241

Post by oxcabe »

9dev wrote: post #221
reubenmorais wrote: post #203

Earlier quoted context omitted.

This is a weakness of the Python typing system and not necessarily of individual typecheckers. Pyright has a policy of only implementing what's standardized, and the Python type system is simply inadequate to annotate most real world Python code out there. It's been years now and something as basic as properly typing kwargs is still not supported. Ty could solve this if they rebel and decide to ignore the Python typi…

Python code feels like back in the day when JavaScript was typed using JSDoc comments, and libraries would use all kinds of fantastical object shapes for their option parameters, so users could pass "just about anything" and it would work. You would never know how to configure an Express app without digging through the documentation, for example. I loathe the Python convention of just using kwargs instead of clearly…

Sometimes, though, you may get lucky, and find some tests for the code you want to use!

On a more serious note, I can't even blame library devs as long as they try. Type "hints" often are anything but _just_ hints. Some are expected to be statically checked; some may alter runtime behavior (e.g. the @overload decorator). It's like the anti-pattern of TypeScript's enums laid out here and there, and it's even harder to notice such side-effects in Python.

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

#242

Post by johnisgood »

lacasito25 wrote: post #217
zo1 wrote: post #187

Earlier quoted context omitted.

You should be doing this dynamically based on the version of python you are running against, so that you don't have to hardcode or make such "conservative" choices by hand.

I think they probably know that, this is alpha software, no need to be condescending.

How is it condescending in any way? I found it to be a constructive criticism; i.e. useful help.

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

#243

Post by cadu2 »

9dev wrote: post #221
reubenmorais wrote: post #203

Earlier quoted context omitted.

This is a weakness of the Python typing system and not necessarily of individual typecheckers. Pyright has a policy of only implementing what's standardized, and the Python type system is simply inadequate to annotate most real world Python code out there. It's been years now and something as basic as properly typing kwargs is still not supported. Ty could solve this if they rebel and decide to ignore the Python typi…

Python code feels like back in the day when JavaScript was typed using JSDoc comments, and libraries would use all kinds of fantastical object shapes for their option parameters, so users could pass "just about anything" and it would work. You would never know how to configure an Express app without digging through the documentation, for example. I loathe the Python convention of just using kwargs instead of clearly…

I'm not sure into what kind of industry you're in, but having most functions as (args, *kwargs) is not the way I deal with most of my code and the libraries I work at all (backend development). Everything is typed fully.

Maybe you're in a niche spot, or using scientist-based code. I've seen plenty of trainwrecks in 'conda-only' ""libraries"" done by scientists. Maybe that's the niche you're at?

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

#244

Post by triyambakam »

ukblewis wrote: post #188
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…

Have you tried SQLModel?

I've tried using it but it's still so immature and poorly documented. I wish it were different because I love the idea of it.

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

#245

Post by renmillar »

tyrion wrote: post #124
dcreager wrote: post #72

Earlier quoted context omitted.

At least for the moment, we aren't planning on a plugin architecture. We do recognize that there are some popular libraries and code patterns that aren't easily (or at all) typeable with the current state of the typing spec. We feel it would be more useful to help drive changes to the typing spec where we can, so that other type checkers can also benefit; and/or implement workarounds for the most popular libraries di…

Helping improve the spec and all is great, but being 100% honest, as a user, I would rather have a type checker I can bend to my needs. As you said, some code patterns in a dynamic language like Python are difficult, or even impossible, to type-check without custom code. Type checkers are becoming more popular than ever, and this implicitly means that these code patterns are are going to be discouraged. On one hand,…

IMO creating custom rules is problematic - when projects import external code, rule conflicts become inevitable. C++'s type system might be complex, but at least there's consistency across header files within a project.

Regarding type checkers: while I don't love optimizing code just to make them run faster, most Python patterns can be implemented in statically checkable ways without much compromise. The benefits typically outweigh the costs. Python's dynamic features are powerful but rarely essential for everyday tasks.

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

#246

Post by renmillar »

dathinab wrote: post #98
HideousKojima wrote: post #38

Earlier quoted context omitted.

>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...

the thing is most (all) of the type checkers including e.g. mypy _do not_ support most crazy python ... 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 mod…

Python's static checking capabilities could significantly improve both tracing and compilation efficiency. The language features that currently limit type checkers are likely the same ones making efficient compilation difficult. Perhaps we'll eventually see a Python 3.40 with complete JIT compilation, functioning similarly to Julia but retaining Python's extensive ecosystem that makes it essential in certain domains.

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

#247

Post by renmillar »

_carljm wrote: post #148
dcreager wrote: post #141

Earlier quoted context omitted.

Wait wait wait Carl, you did not tell me that the errors we emit need to be correct !! I think I need to go revisit some of my PRs...

I knew we left something important out of that onboarding document

Why don't you just run ty on the ty codebase and let it tell you which errors are correct and which are erroneous?

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

#248

Post by digdugdirk »

_carljm wrote: post #128
akdor1154 wrote: post #120

Earlier quoted context omitted.

Yeah.. Have either of the ty / pyrefly teams reached out to the other? I feel like the community does not really need two fast python type checkers. (However, vc-backed astral probably need control over theirs to keep monetization options open, and Facebook probably need control over theirs so it can be targeted at Facebook's internal cool-but-non-standard python habits... Sigh. Why do we have nice things? Money. Why…

Yes, we've talked; I know a number of the pyrefly devs well. Ty had already been months in development when pyrefly development started. We discussed collaboration, but they decided they needed to do their own thing in order to move quickly and ensure it would serve their needs, which is totally reasonable.

It looks like both projects seem to use Ruff at their core, is there any documentation that describes the differences in each project's approach?

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

#249

Post by urbandw311er »

Philpax wrote: post #230
rc00 wrote: post #166

Earlier quoted context omitted.

The timing of the recent batch of propaganda makes it hard to believe it's not coordinated. I wouldn't suggest paid actors but maybe just an attempt to counter some fairly visible and negative recent takes. The amount of "I love Rust but" comments make it hard to take the commentary seriously too.

Is it really that hard to believe that people like the language and the problems it solves for them?

I think what stands out (and becomes quite tedious) is that most posts on HN don’t tend to include the language choice in the headline.

So a typical HN post might be “A new widget that saves times rendering Python code”. Whereas we get this constant barrage of “A new widget that saves times rendering Python code in Rust” with Rust appended to it.

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

#250

Post by urbandw311er »

urbandw311er wrote: post #249
Philpax wrote: post #230

Earlier quoted context omitted.

Is it really that hard to believe that people like the language and the problems it solves for them?

I think what stands out (and becomes quite tedious) is that most posts on HN don’t tend to include the language choice in the headline. So a typical HN post might be “A new widget that saves times rendering Python code”. Whereas we get this constant barrage of “A new widget that saves times rendering Python code in Rust” with Rust appended to it.

PS: just to explain, the original post title was like this but it has now been modified to remove Rust.
Post reply on HN