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

141–150 of 181 posts

Re: Announcing the Beta release of ty

#141

Post by collinmanderson »

CyberThijs wrote: post #127
SSchick wrote: post #64

Earlier quoted context omitted.

https://github.com/python/typing/pull/2137 PR is somewhat WIP-ish but I needed some motivation to do OSS work again :)

For those interested: the results page in this PR looks like this: https://htmlpreview.github.io/?https://github.com/SimonSchic...

Thanks.

I really need better generics support before ty becomes useful. Currently decorators just make all return types unknown. I need something this to work:

    _F = TypeVar("_F", bound=Callable[..., Any])
    def my_decorator(*args: str) -> Callable[[_F], _F]: ...
Also, I use a lot of TypedDicts and there's not much support yet.

Re: Announcing the Beta release of ty

#142

Post by linhns »

caidan wrote: post #115

You guys are a godsend to the python tooling world. I’ve been far more excited about the impact rust is having on the software world than that of AI, and your work is a big part of that. While I have not seen any real net productivity gains from AI in mine or my juniors work, I’ve definitely seen real gains from using your tooling! In fact as Jetbrains has been spending years chasing various rabbits including AI, ins…

Nice to see Pycharm going downhill being mentioned. Nice tool in the past, not much so now.

Re: Announcing the Beta release of ty

#143

Post by linhns »

WD-42 wrote: post #28
frou_dh wrote: post #6

Hopefully it gets added to this comparison: https://htmlpreview.github.io/?https://github.com/python/typ... If that table is anything to go by, Pyright is not to be underestimated. I have briefly tried ty (LSP) in Emacs and it seems to work well so far. The only questionable thing I've encountered is that when the signature of a method is shown, the type annotations of some parameters seem to be presented in a partic…

Pyright has been great. But it’s slow. Speed of a LSP does matter for UX. Excited to see how much ty improves on this.

Pyright is a type checker, not a LSP per se in my opinion. ty is both.

Re: Announcing the Beta release of ty

#144

Post by zanie »

benrutter wrote: post #140
japhyr wrote: post #132

Earlier quoted context omitted.

I believe the've been looking for two-letter names that aren't already taken, and are easy to type. I think I heard that from one of the podcasts that Charlie Marsh was on.

Source here for anyone interested[0]. From memory, Ruff was its own thing, (I think named after the bird?) since then they've tried to give projects short letter combinations for consistency and ease of typing (uv, ty, pyx) [0] https://talkpython.fm/episodes/download/520/pyx-the-other-si...

Ruff wasn't named after the bird, we just think it's funny that Charlie didn't know it was a bird. He made up the word :)

Re: Announcing the Beta release of ty

#145

Post by jitl »

xixixao wrote: post #113
hauntsaninja wrote: post #69

Earlier quoted context omitted.

The conformance test suite is currently mostly focused on “what does an explicit type annotation mean” A shared spec for this is important because if you write a Python library, you don’t want to have to write a different set of types for each Python type checker Here are some things the spec has nothing to say about: Inference You don’t want to annotate every expression in your program. Type checkers have a lot of l…

In case you’re not well versed in Python typecheckers, in the mypy vs Pyright example, Pyright can be configured to complain about not annotating the collection (and so both typecheckers will yell at the code as written). TypeScript takes the same approach in this scenario, and I assume this helps both be fast.

TypeScript will use flow typing to determine the type as number[] in this code:

    const x = []
    x.push(1)
    type t = typeof x // number[]

Re: Announcing the Beta release of ty

#146

Post by jitl »

dwattttt wrote: post #86
MangoToupe wrote: post #83

Earlier quoted context omitted.

It doesn't. Either the optional type annotations have precise semantics or they don't.

What should a type checker say about this code? x = [] x.append(1) x[0] = "new" x[0] + "oops" It's optionally typed, but I would credit both "type checks correctly" and "can't assign 'new' over a number" as valid type checker results.

TypeScript widens the type of x to allow `number | string`, there are no type errors below:

    const x = []
    x.push(1)
    type t = typeof x
    //   ^? type t = number[]
    x[0] = "new"
    type t2 = typeof x
    //   ^? type t2 = (number | string)[]
    const y = x[0] + "oops"
    //    ^? const y: string
https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABA...

Re: Announcing the Beta release of ty

#147

Post by collinmanderson »

zanie wrote: post #144
benrutter wrote: post #140

Earlier quoted context omitted.

Source here for anyone interested[0]. From memory, Ruff was its own thing, (I think named after the bird?) since then they've tried to give projects short letter combinations for consistency and ease of typing (uv, ty, pyx) [0] https://talkpython.fm/episodes/download/520/pyx-the-other-si...

Ruff wasn't named after the bird, we just think it's funny that Charlie didn't know it was a bird. He made up the word :)

I've always assumed it was something like:

ruff - "RUst Formatter".

ty - "TYpe checker"

uv - "Unified python packaging Versioner"? or "UniVersal python packaging"

Re: Announcing the Beta release of ty

#148

Post by polski-g »

woodruffw wrote: post #68
bmitc wrote: post #55

Earlier quoted context omitted.

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

If there are specific incompatibilities or rough edges you're running into, we're always interested in hearing about them. We try pretty hard to provide a pip compatibility layer[1], but Python packaging is non-trivial and has a lot of layers and caveats. [1]: https://docs.astral.sh/uv/pip/

uv needs to support creation of zipapps, like pdm does (what pex does standalone).

Various tickets asking for it, but they also want to bundle in the python interpreter itself, which is out of scope for a pyproject.toml manager: https://github.com/astral-sh/uv/issues/5802

Re: Announcing the Beta release of ty

#149

Post by jghn »

codys wrote: post #58
SmileyKeith wrote: post #48

Earlier quoted context omitted.

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.

I can't recall a single time that type-checker speed was the limiting factor for me.

Re: Announcing the Beta release of ty

#150

Post by xixixao »

solvedd wrote: post #118
xixixao wrote: post #113

Earlier quoted context omitted.

In case you’re not well versed in Python typecheckers, in the mypy vs Pyright example, Pyright can be configured to complain about not annotating the collection (and so both typecheckers will yell at the code as written). TypeScript takes the same approach in this scenario, and I assume this helps both be fast.

They were "on the Python Typing Council and helped put together the spec, the conformance test suite, etc" so I assume they are an expert on Python typecheckers

I didn’t write it for parent lol. I guess I should be more careful with “you”.
Post reply on HN