81–90 of 181 posts
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.
And what do you use instead?
Earlier quoted context omitted.
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.
Is it wrong to to say that I don't like pyright on principle because it requires node.js and npm to install and run?
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?
You’re talking about a duck typed language with optional type annotations. I love python but that’s a combination that should explain a bit why there are so many different implementations.
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…
> but pyright will not (because it infers the types of unannotated collections as having Any) This is incorrect. pyright will infer the type of x as list[Unknown].
Unknown is a pyright specific term for inferred Any that is used as the basis for enabling additional diagnostics prohibiting gradual typing.
Notably, this is quite different from TypeScript’s unknown, which is type safe.
Earlier quoted context omitted.
You’re talking about a duck typed language with optional type annotations. I love python but that’s a combination that should explain a bit why there are so many different implementations.
It doesn't. Either the optional type annotations have precise semantics or they don't.
x = []
x.append(1)
x[0] = "new"
x[0] + "oops"
Earlier quoted context omitted.
You’re talking about a duck typed language with optional type annotations. I love python but that’s a combination that should explain a bit why there are so many different implementations.
It doesn't. Either the optional type annotations have precise semantics or they don't.
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.
Either way, you didn't annotate the code so it's kind of pointless to discuss.
Also fwiw python is typed regardless of the annotations; types are not optional in any sense. Unless you're using BCPL or forth or something like that
It's fast too as promised.
However, it doesn't work well with TypedDicts and that's a show-stopper for us. Hoping to see that support soon.
Displaying inferred types inline is a killer feature (inspired from rust lang server?). It was a pleasant surprise! It's fast too as promised. However, it doesn't work well with TypedDicts and that's a show-stopper for us. Hoping to see that support soon.