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

161–170 of 296 posts

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

#161

Post by miki123211 »

_carljm wrote: post #30
mjr00 wrote: post #23

Earlier quoted context omitted.

> The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. Or in this case, writing it in Rust... mypy is written in Python. People have forgotten that Python is really, really slow for CPU-intensive operations. Python's performance may not matter when you're writing web service code and the bottlenecks are database I/O and network calls, but for a tool that's…

(ty developer here) Currently we default to our oldest supported Python version, in which `datetime.UTC` really doesn't exist! Use `--python-version 3.12` on the CLI, or add a `ty.toml` with e.g. ``` [environment] python-version = "3.12" ``` And we'll find `datetime.UTC`. We've discussed that this is probably the wrong default, and plan to change it.

I realize this might be hard from a technical / architecture standpoint, but it would be great if "does not exist" and "does not exist in this version of Python" were two different errors.

If I saw something like "datetime.UTC doesn't exist", I'd immediately think "wait, was that datetime.utc", not "ooh it got added in 3.11, I need to change my Python version"

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

#162

Post by collinmanderson »

12_throw_away wrote: post #43
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…

If you can say - are there any thoughts about implementing plugins / extension capabilities to keep type checking working even with libraries that aren't otherwise typecheckable? (where "not otherwise typecheckable" means types that can't be expressed with stubs - e.g., Django, dataclasses pre-PEP-681, pytest fixtures, etc.)

https://pypi.org/project/django-types/ is compatible with pyright without plugins, so it should theoretically work with ty. It might not check as much as mypy though especially with values() querysets.

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

#163

Post by jez »

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,…

Out of curiosity, do you have experience with other languages that have type system plugins that you’d hope be used as inspiration for something in Python?

I don’t have any such experience (short of a macro system, which requires code generation or runtime support) and it always makes me curious when people ask for type system plugins whether this is a standard feature in a type system I’ve never used.

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

#164

Post by [deleted] »

kstrauser wrote: post #116
usr9012809 wrote: post #115

Earlier quoted context omitted.

> Pre-alpha are much better as .dev releases. No, they are correctly using semantic versioning to indicate pre-alpha releases. https://github.com/astral-sh/ty/releases https://semver.org/

Python doesn’t use plain semver: https://peps.python.org/pep-0440/

[deleted]

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

#165

Post by rtpg »

mil22 wrote: post #3
tmvphil wrote: post #2

Just compared the time to check on a fairly large project: - mypy (warm cache) 18s - ty: 0.5s (and found 3500 errors) They've done it again.

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

I would like to just not use it, but the existence of pyright as a _barely_ functional alternative really sucks the air out of other attempts' continued existence. Real "extend/extinguish" behavior from MSFT.

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

#166

Post by rc00 »

urbandw311er wrote: post #70

It’s like when we hit a new month the quota of “talk about Rust” credits is renewed.

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.

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

#169

Post by bdzr »

__MatrixMan__ wrote: post #157
codr7 wrote: post #136

Earlier quoted context omitted.

From my experience it's VERY rare for people to pay for anything unless they're forced, I do the same thing even though I'm very aware of the need for compensating creators. Talk is cheap, and people talk a lot about supporting projects. Maybe if we could make some kind of statistics over the number of projects that were abandoned because maintainers didn't feel like working and dealing with random people for free an…

That has been my experience as well. I consider it a bug. 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. Make like, a week long "holiday" where you either verify that your company has made an adequate donation to the OSS maintainers that make…

> 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 for stuff, have a free tier, enjoy sustainable software.

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

#170

Post by spooky_action »

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…

It's not perfect, but runtime_checkable is a thing https://docs.python.org/3/library/typing.html#typing.runtime...

It doesn't actually preserve typing on the protocol's methods though

Post reply on HN