Django support will be a game changer on top of the game changer ty is!
Announcing the Beta release of ty
91–100 of 181 posts
Re: Announcing the Beta release of ty
#92Earlier quoted context omitted.
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.
It depends on the semantics the language specifies. Whether or not the annotations are optional is irrelevant. 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
> Either way, you didn't annotate the code so it's kind of pointless to discuss.
There are several literals in that code snippet; I could annotate them with their types, and this code would still be exactly as it is. You asked why there are competing type checkers, and the fact that the language is only optionally typed means ambiguity like that example exists, and should be a warning/bug/allowed; choose the type checker that most closely matches the semantics you want to impose.
Re: Announcing the Beta release of ty
#93I 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?
Users of a library will generally instruct their type-checker not to check the library.
So only the outer API surface of the library matters. That’s mostly explicitly typed functions and classes so the room for different interpretations is lower (but not gone).
This is obviously out the window for libraries like Pydantic, Django etc with type semantics that aren’t really covered by the spec.
Re: Announcing the Beta release of ty
#94I 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, whi…
Damn it, this unicorn farting rainbows and craping gold is not yet capable of towing another car. I don't know why they advertise it as a replacement for my current mode of transportation.
Re: Announcing the Beta release of ty
#95Super excited about this generally ok satisfied with pyright but so I was with conda before uv or black before ruff.
Re: Announcing the Beta release of ty
#96Earlier quoted context omitted.
It depends on the semantics the language specifies. Whether or not the annotations are optional is irrelevant. 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
> Either way, you didn't annotate the code so it's kind of pointless to discuss. There are several literals in that code snippet; I could annotate them with their types, and this code would still be exactly as it is. You asked why there are competing type checkers, and the fact that the language is only optionally typed means ambiguity like that example exists, and should be a warning/bug/allowed; choose the type che…
> There are several literals in that code snippet; I could annotate them with their types, and this code would still be exactly as it is.
Well, no, there is one literal that has an ambiguous type, and if you annotated its type, it would resolve entirely the question of what a typechecker should say; literally the entire reason it is an open question is because that one literal is not annotated.
Re: Announcing the Beta release of ty
#97Earlier 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.
The annotations have fairly well defined semantics, the behavior of typecheckers in the absence of annotations, where types are ambiguous (a common case being when the type is a generic collection type but the defining position is assignment to an empty collection so that the correct specialization of the generic type is ambiguous) is less defined.
Re: Announcing the Beta release of ty
#98Displaying 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.
We should generally support TypeDicts. Can you go into more details of what is not working for you?
```
from anthropic.types import MessageParam
data: list[MessageParam] = [{"role": "user", "content": [{"type": "text", "text": ""}]}]
```
This for example works both in mypy and pyright. (Also autocompletion of typedict keys / literals from pylance is missing)
Re: Announcing the Beta release of ty
#99Earlier quoted context omitted.
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
> 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.
Re: Announcing the Beta release of ty
#100Earlier quoted context omitted.
> Either way, you didn't annotate the code so it's kind of pointless to discuss. There are several literals in that code snippet; I could annotate them with their types, and this code would still be exactly as it is. You asked why there are competing type checkers, and the fact that the language is only optionally typed means ambiguity like that example exists, and should be a warning/bug/allowed; choose the type che…
> There are several literals in that code snippet; I could annotate them with their types, and this code would still be exactly as it is. Well, no, there is one literal that has an ambiguous type, and if you annotated its type, it would resolve entirely the question of what a typechecker should say; literally the entire reason it is an open question is because that one literal is not annotated.
True, you could annotate 3 of the 4 literals in this without annotating the List, which is ambiguous. In the absence of an explicit annotation (because those are optional), type checkers are left to guess intent to determine whether you wanted a List[Any] or List[number | string], or whether you wanted a List[number] or List[string].