131–140 of 181 posts
Too bad they did not benchmark Zuban, which is also promising. Also, it's also too bad we have three competing fast LSP/typechecker projects now We had zero 1 year ago.
The guy behind Zuban should've put his project out the in open way earlier. I'd love to see both projects succeed, but in reality it should become one.
Slight tangent I recently viewed tutorials on uv and ruff from Corey Schafer on youtube which were excellent Hope to make these tools part of my defaults Look forward a similar overview by Corey on ty :) Curious ..is there any backstory to these library names?
Python programmers are crying out for types it seems. It’s a shame the Python foundation haven’t blessed a spec. Better to get everyone working on a single slightly imperfect standard than a morass or differing ideas.
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.
I think it is way to slow too. The one from microsoft (pylance IIRC) is better in my opinion.
Earlier 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…
Well, no, you didn't. Because it's not clear whether the list is a list of value or a list of values of a distinct type. And there are many other ways you could quibble with this statement.
Earlier quoted context omitted.
> 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].
Optimally, this will result in a democratic consensus of semantics.
Pessimistically, this will result in dialects of semantics that result in dialects of runtime languages as folks adopt type checkers.
Python programmers are crying out for types it seems. It’s a shame the Python foundation haven’t blessed a spec. Better to get everyone working on a single slightly imperfect standard than a morass or differing ideas.
Could you elaborate on what you mean? There are various typing PEPs; they even have their own category[1]. [1]: https://peps.python.org/topic/typing/
We've been relying on TypeForm (an experimental feature in Pyright) in xDSL. Since there are some Astral members commenting here: are there any plans to support TypeForm any time soon? It seems like you already have some features that go beyond the Python type spec, so I feel like there may be hope
[1] https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc142...
[2] https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc142...
Earlier quoted context omitted.
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].
Right. And the fact that python doesn't specify the semantics of its type annotations is a super interesting experiment. Optimally, this will result in a democratic consensus of semantics. Pessimistically, this will result in dialects of semantics that result in dialects of runtime languages as folks adopt type checkers.
That hasn't been a fact for quite a while. Npw, it does specify the semantics of its type annotations. It didn't when it first created annotations for Python 3.0 (PEP 3107), but it has progressively since, starting with Python 3.5 (PEP 484) through several subsequent PEPs including creation of the Python Typing Council (PEP 729).
Slight tangent I recently viewed tutorials on uv and ruff from Corey Schafer on youtube which were excellent Hope to make these tools part of my defaults Look forward a similar overview by Corey on ty :) Curious ..is there any backstory to these library names?
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.
[0] https://talkpython.fm/episodes/download/520/pyx-the-other-si...