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

Announcing the Beta release of ty

astral.sh

Post reply on HN
Print view View original

51–60 of 181 posts

Re: Announcing the Beta release of ty

#51

Post by gwking »

shrumm wrote: post #36

Thanks Astral team! We use Pydantic heavily, and it looks like first class support from Ty is slated for the stable release, we'd love to try it. While we wait... what's everyone's type checking setup? We run both Pyright and Mypy... they catch different errors so we've kept both, but it feels redundant. https://htmlpreview.github.io/?https://github.com/python/typ... suggests that Pyright is a superset, which hasn't…

I appreciate the even tempered question. I’ve been using mypy since its early days, and when pyright was added to vs code I was forced to reckon with their differences. For the most part I found mypy was able to infer more accurately and flexibly. At various times I had to turn pyright off entirely because of false positives. But perhaps someone else would say that I’m leaning on weaknesses of mypy; I think I’m pretty strict but who knows. And like yourself, mine is a rather dated opinion. It used to be that every mypy release was an event, where I’d have a bunch of new errors to fix, but that lessened over the years.

I suspect pyright has caught up a lot but I turned it off again rather recently.

For what it’s worth I did give up on cursor mostly because basedpyright was very counterproductive for me.

I will say that I’ve seen a lot more vehement trash talking about mypy and gushing about pyright than vice versa for quite a few years. It doesn’t quite add up in my mind.

Re: Announcing the Beta release of ty

#52

Post by [deleted] »

conception wrote: post #50
progbits wrote: post #18

Earlier quoted context omitted.

pyright is very good, but there is also https://docs.basedpyright.com/latest/ which improves on it further. That said I'm very happy user of uv, so once Ty becomes ready enough will be happy to migrate.

Basedpyright plus any AI generated python is a hellscape unless you use hooks and have a lot of patience.

[deleted]

Re: Announcing the Beta release of ty

#54

Post by dcre »

SmileyKeith wrote: post #48
hauntsaninja wrote: post #41

Earlier quoted context omitted.

Note: while spec conformance is important, I don't recommend using it as the basis for choosing a type checker. It is not representative of the things that most users actually care about (and is not meant to be). (I was on the Python Typing Council and helped put together the spec, the conformance test suite, etc)

Can you add some examples of the things users care about that aren't well covered by this? I empathize with everyone who wants a feature comparison chart so they can be confident switching without unknowingly losing important safety checks.

I think the idea is not that there are features that aren’t listed, but rather that if a typechecker supports 10 features people care about and is missing 10 that people don’t really use, it will look a lot worse on a list like this than a typechecker with 100% compliance, when in practice it may not really be worse at all.

Edit: Based on this other comment, the point was also about things not covered by the spec. “The spec mostly concerns itself with the semantics of annotations, not diagnostics or inference.” https://news.ycombinator.com/item?id=46296360

Re: Announcing the Beta release of ty

#55

Post by bmitc »

klysm wrote: post #21

I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.

My issue with them is that they claim their tools replace existing tools, but they don't bother to actually replicate all of the functionality. So if you want to use the full functionality of existing tools, you need to fall back on them instead of using Astral's "replacements". It's like one step forward and one step back. For me personally, speed of the tooling is not as important as what the tooling can check, which is very important for a language like Python that is very easy to get wrong.

Re: Announcing the Beta release of ty

#57

Post by mikepurvis »

pansa2 wrote: post #22

I still don’t understand how a single language can have multiple (what is it now, half a dozen?) different type checkers, all with different behaviour. Do library authors have to test against every type checker to ensure maximum compatibility? Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?

At least some of it is differing policies on what types can be inferred/traced through the callers vs what has to be given explicitly.

I think everyone basically agrees that at the package boundary, you want explicit types, but inside application code things are much more murky.

(plus of course, performance, particularly around incremental processing, which Astral is specifically calling out as a design goal here)

Re: Announcing the Beta release of ty

#58

Post by codys »

SmileyKeith wrote: post #48
hauntsaninja wrote: post #41

Earlier quoted context omitted.

Note: while spec conformance is important, I don't recommend using it as the basis for choosing a type checker. It is not representative of the things that most users actually care about (and is not meant to be). (I was on the Python Typing Council and helped put together the spec, the conformance test suite, etc)

Can you add some examples of the things users care about that aren't well covered by this? I empathize with everyone who wants a feature comparison chart so they can be confident switching without unknowingly losing important safety checks.

The chart does not describe speed (either in general or in any particular case). Speed/performance/latency is a thing users care about that is not included in the feature list.

Re: Announcing the Beta release of ty

#59

Post by sails01 »

bmitc wrote: post #56
sails01 wrote: post #45

Is there any study that shows that typing in Python improves code quality and reduce runtime issues?

That's equivalent to asking if there are benefits of static typing.

Not quite, static typing is used at runtime, python type annotations are not

Re: Announcing the Beta release of ty

#60

Post by shrumm »

gwking wrote: post #51
shrumm wrote: post #36

Thanks Astral team! We use Pydantic heavily, and it looks like first class support from Ty is slated for the stable release, we'd love to try it. While we wait... what's everyone's type checking setup? We run both Pyright and Mypy... they catch different errors so we've kept both, but it feels redundant. https://htmlpreview.github.io/?https://github.com/python/typ... suggests that Pyright is a superset, which hasn't…

I appreciate the even tempered question. I’ve been using mypy since its early days, and when pyright was added to vs code I was forced to reckon with their differences. For the most part I found mypy was able to infer more accurately and flexibly. At various times I had to turn pyright off entirely because of false positives. But perhaps someone else would say that I’m leaning on weaknesses of mypy; I think I’m prett…

> I will say that I’ve seen a lot more vehement trash talking about mypy and gushing about pyright than vice versa for quite a few years. It doesn’t quite add up in my mind.

agreed! mypy's been good to us over the years.

The biggest problem we're looking to solve now is raw speed, type checking is by far the slowest part of our precommit stack which is what got us interested in Ty.

Post reply on HN