Top
Best
New

Posted by gavide 12/16/2025

Announcing the Beta release of ty(astral.sh)
853 points | 176 commentspage 4
sails01 7 days ago|
Is there any study that shows that typing in Python improves code quality and reduce runtime issues?
kurtis_reed 7 days ago||
Newsflash: not everything good has a study about it
wiseowise 7 days ago|||
> Ughm, is there any study that shows that guardrails and lights on bridges reduce fatalities?

> Akshually, are there any studies showing that cars riding 30 km/h kill less people than cars that ride 80 km/h?

dllthomas 7 days ago||
I think there are both of those.
bmitc 7 days ago|||
That's equivalent to asking if there are benefits of static typing.
pansa2 7 days ago|||
Specifically, it's like asking if there are any studies that demonstrate benefits of static typing. Are there?
sails01 7 days ago|||
Not quite, static typing is used at runtime, python type annotations are not
dragonwriter 7 days ago|||
> Not quite, static typing is used at runtime, python type annotations are not

No, static typing is usually used AOT (most frequently at compile time), not usually at runtime (types may or may not exist at runtime; they don't in Haskell, for instance.)

Python type checking is also AOT, but (unlike where it is inextricably tied to compilation because types are not only checked but used for code generation) it is optional to actually do that step.

Python type annotations exist and are sometimes used at runtime, but not usually at that point for type checking in the usual sense.

tome 7 days ago||
> > Not quite, static typing is used at runtime, python type annotations are not

> No, static typing is usually used AOT (most frequently at compile time), not usually at runtime (types may or may not exist at runtime; they don't in Haskell, for instance.)

In fact, Haskell then allows you to add back in runtime types using Typeable!

https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-...

amethyst 7 days ago||||
tools like dataclasses and pydantic would like to have a word...
wiseowise 7 days ago|||
> static typing is used at runtime

Educate yourself before making such claims.

hexo 7 days ago|||
Well, it's just a documentation suggestion for user. Having for me about same value as if it was written in pydoc. I'd really love to see such study as well
sails01 7 days ago||
Agree, we already had a solution documenting types in docstring.

In my case they just add noise when reading code and make it more difficult to review

solarkraft 7 days ago||
it has been consensus for decades at this point.
almanael 12/16/2025||
Not impressed because when tried ruff, and discovered that it doesn't replace (basic) pylint check https://github.com/astral-sh/ruff/issues/970 so we have ruff then pylint (and looking at the number of awaiting PR of ruff feels bad)
zanie 12/16/2025||
As noted in the linked issue

> At time of writing, many of the remaining rules require type inference and/or multi-file analysis, and aren't ready to be implemented in Ruff.

ty is actually a big step in this direction as it provides multi-file analysis and type inference.

(I work at Astral)

int_19h 6 days ago||
Are you guys planning to tackle Python debugging next? pydevd could really use a fast native rewrite targeting modern Python.
caidan 7 days ago||
Ruff is incredible, replacing a mountain of tools and rules with a single extremely fast linter/formatter. Given that it is updated and improved frequently, I’m curious if you have tried it recently, and if so what pylint rules are you using that it doesn’t cover?
syiblet 12/16/2025|
The codebase has none of the rust code. In fact even the python code in the code base is mostly just scripts for updating version tags and etc...

Seems like the code isn't actually open source which to me is a bit concerning. At the very least, if ya'll want to release it like this please be clear that you're not open source. The MIT license in the repo gives the wrong impression.

woodruffw 12/16/2025||
The ty repo contains the ruff repo[1] as a submodule, where the remainder of the code is. It is indeed open source, the layout is just indirect at the moment because of code-sharing between the tools.

[1]: https://github.com/astral-sh/ruff

zanie 12/16/2025||
This is also documented at https://github.com/astral-sh/ty?tab=readme-ov-file#contribut... and https://github.com/astral-sh/ty/blob/main/CONTRIBUTING.md#re...
simonw 12/16/2025|||
I think that's because most of the code for `ty` is tucked away in the `ruff` codebase: https://github.com/astral-sh/ruff/tree/main/crates/ty - it's all MIT licensed.
bobthecowboy 12/16/2025||
At least as of a couple months ago, `ty` was actually being developed in the `ruff` repo (per an pdocast interview the devs did on Talk Python), so that might be why the `ty` repo looks empty (and pulls in ruff as a git submodule).