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

Pyrefly: Python type checker and language server in Rust

pyrefly.org

Post reply on HN
Print view View original

141–150 of 150 posts

Re: Pyrefly: Python type checker and language server in Rust

#141

Post by pjmlp »

wiseowise wrote: post #75
arccy wrote: post #52

Earlier quoted context omitted.

yeah we all heard that story every 3 months with all the previous package managers. until there's adoption by an overwhelming majority of projects, it isn't really settled yet.

I’ve literally never heard that much buzz and excitement about Python tool before. And I’ve seen them all. All of them had some big issue that prevented it from getting mainstream. Either it was slow, or didn’t work with existing workflow, or had complex configuration, or something that prevented gradual adoption. uv is universally praised as the second coming Christ in Python world (and for a good reason). So no, I…

Using Python in one form or the other since Python 1.6, there is always some buzz for whatever tool now and then.

Re: Pyrefly: Python type checker and language server in Rust

#142

Post by dmurray »

fragmede wrote: post #130
dmurray wrote: post #127

Earlier quoted context omitted.

Type checking in Python involves guessing. Take a program like x = [3] Should the type checker guess that the type of x is list[Any], or list[int], or list[Literal[3]], or something else? Libraries you depend on will pose more difficult versions of this question. So it's not possible to expect the tool to be "perfect", whatever that means - usually people think of it as meaning it allows all code that they think is i…

Arguably it's the job of a linter and not a type checker, but if your code just assigns random things to random variables that never get used again, I hope something would point that out to you before it passes code review and merged to main, ideally before it even gets sent for review. Ignoring the question of why there's some random assignment to x in the first place, where are its type hints? Those were added star…

> Ignoring the question of why there's some random assignment to x in the first place, where are its type hints? Those were added starting with Python 3.5 via PEP 484 just over 10 years ago and have been added to since then.

The code is in a third party library which doesn't have comprehensive type hints, and perhaps has type expectations so complicated that they can't be expressed in the Python type system.

Even if you enforce type hints on every line in your internal code, you're going to be relying at some point on libraries which are reliable but poorly type hinted. If you're not using that vast ecosystem of libraries, Python probably wasn't the best choice.

Re: Pyrefly: Python type checker and language server in Rust

#143

Post by jswny »

charliermarsh wrote: post #103
jswny wrote: post #47

Earlier quoted context omitted.

At least for Ty, not sure about the others, it is explicitly for type checking, exposed as an LSP. It’s not trying to compete with full LSP implementations. Most modern editors let you combine multiple LSPs, you shouldn’t think of them as using only one at a time

We actually do want ty to be a first-class LSP (i.e., a complete alternative to Pylance and others), and it already supports nearly all of the features you'd expect. I use it as my primary LSP today in lieu of Pylance!

Good to know, I had no idea!

Re: Pyrefly: Python type checker and language server in Rust

#144

Post by eqvinox »

sh34r wrote: post #137
eqvinox wrote: post #90

Earlier quoted context omitted.

Yes, annotating the type explicitly fixes it; but tbh I'd consider that type annotation "unnecessary/distracting code litter". As far as their philosophy goes, it's an open issue they're working on, so their philosophy seems to agree this particular pattern should work :)

It is a purely subjective design decision, but I personally prefer the stricter rules that don’t do backwards type inferences like this… type hints shouldn’t follow duck typing semantics. Otherwise you’re not providing nearly as much value IMO. Typescript is really the model organism here. They took the most cursed mainstream programming language, and made it downright good . Today, the “: list[str]” is 11 wasted cha…

> Today, the “: list[str]” is 11 wasted characters and it’s not as aesthetically pleasing. Tomorrow, you do some refactor and your inferred list[str] becomes a list[int] without you realizing it… I’m sure that sounds silly in this toy example, but just imagine it’s a much more complex piece of code.

Hmm. I'm looking at a codebase that is still in a lot of "early flux", where one day I might be looking at a "list[VirtualRouter]" but the next day it's a "list[VirtualRouterSpec]". It's already gone through several refactors and it kinda felt like the type hints were pretty much spot on in terms of effort-benefit. It's not a legacy codebase; it has reasonably good type hint coverage, but it's focused on type hinting interfaces (a few Protocol in there), classes and functions. The type hinting inline in actual code is limited.

I do understand your perspective, but tbh to me it feels like if I went that far I might rather not choose Python to begin with…

Re: Pyrefly: Python type checker and language server in Rust

#145

Post by phplovesong »

coldtea wrote: post #89
phplovesong wrote: post #67

Earlier quoted context omitted.

If typechecking is tongue on cheek, why even bother?

Because "all or nothing" is a bad idea.

How so? We have multiple languages with static types, and most know the insane benefit you get from having compile time guardrails.

Re: Pyrefly: Python type checker and language server in Rust

#146

Post by phplovesong »

atoav wrote: post #80
phplovesong wrote: post #67

Earlier quoted context omitted.

If typechecking is tongue on cheek, why even bother?

If car crashes still kill people, why wear safety belts?

Thats a bad analogy. A better one is should we check the breaks before (compile time) we start the car and drive down the highway (runtime).

At this point you either did check the breaks, or did not. If not you are out of luck if the breaks did infact not work.

Re: Pyrefly: Python type checker and language server in Rust

#147

Post by phailhaus »

flanked-evergl wrote: post #131
phailhaus wrote: post #126

Earlier quoted context omitted.

> I can’t hold that against the type system. I think we should. Dataclasses have existed in Python for an extremely long time, and yet the type system doesn't support defining your own similar classes. Kwargs have also existed forever, but they forgot to support that and had to add TypedDict's much later. And it still doesn't properly support optional fields. There's a lot of stuff like this in the language which are…

Dataclasses support optional fields and kwargs perfectly. Not sure what you are talking about. I don't think you understand what Pydantic brings to the table or why people use it. It has lots more to do with serialization, complex validation and data mapping.

kwargs are not dataclasses, they are dicts. TypedDict was shoehorned in later to allow typing dicts, but they are so poorly designed that you can't mark individual fields as optional.

Re: Pyrefly: Python type checker and language server in Rust

#148

Post by fastasucan »

phplovesong wrote: post #146
atoav wrote: post #80

Earlier quoted context omitted.

If car crashes still kill people, why wear safety belts?

Thats a bad analogy. A better one is should we check the breaks before (compile time) we start the car and drive down the highway (runtime). At this point you either did check the breaks, or did not. If not you are out of luck if the breaks did infact not work.

Or you test the breaks as you stop to see that everything is clear as you exit your driveway and go into the street.

Re: Pyrefly: Python type checker and language server in Rust

#149

Post by phailhaus »

flanked-evergl wrote: post #128
phailhaus wrote: post #125

Earlier quoted context omitted.

There is no facility in the type system to express the idea that "whatever class attributes are defined, those are kwargs to the init function". That's hacked in using extra typechecker plugins. That's why we're sitting around talking about if a particular typechecker "supports pydantic", rather than it just working.

There is a way to indicate whatever class attributes are defined, those are kwargs to the init function. For one, you can use `kw_only` on the dataclass decorator [1], alternatively you can use the `kw_only` arg on the field function [2]. [1]: https://docs.python.org/3/library/dataclasses.html#dataclass... [2]: https://docs.python.org/3/library/dataclasses.html#dataclass...

That's only for dataclasses, you can't implement your own class like this without implementing it as a dataclass, because the typechecking for it is hacked in as a custom plugin.

What I'm trying to point out is that these features exist in core Python and yet the type system they built can't express it. By contrast, TypeScript is designed in such a way that you can implement everything yourself without having to write "custom typescript checker plugins".

Re: Pyrefly: Python type checker and language server in Rust

#150

Post by phplovesong »

fastasucan wrote: post #148
phplovesong wrote: post #146

Earlier quoted context omitted.

Thats a bad analogy. A better one is should we check the breaks before (compile time) we start the car and drive down the highway (runtime). At this point you either did check the breaks, or did not. If not you are out of luck if the breaks did infact not work.

Or you test the breaks as you stop to see that everything is clear as you exit your driveway and go into the street.

This sounds like the typical "its good enough" argument. Say we test the breaks manually nine times of of ten. This means we get really hard to diagnose bugs because "this did work when i tested locally". And users get more runtime errors because of half-assed development.

Type systems should be treated like maths, its either correct, or not. In the end, a typesystem is basically just that, its math behind the scenes, more specifically a genre of maths called category theory.

Post reply on HN