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

131–140 of 150 posts

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

#131

Post by flanked-evergl »

phailhaus wrote: post #126
kstrauser wrote: post #55

Earlier quoted context omitted.

The type system’s alright. It just gets especially tricky when you’re trying to check code which won’t exist until you run it. For instance, suppose you wanted to load your own module from a database with something like foo = eval(result) It can’t know what you’re going to load until it actually does it. Things which lean heavily into metaprogramming, typically ORMs or things like Pydantic, fall into that category. I…

> 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.

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

#132

Post by mixmastamyk »

flanked-evergl wrote: post #129
mixmastamyk wrote: post #106

Earlier quoted context omitted.

Why would they need to support pydantic when it uses standard annotations? I tried it with ty yesterday and it flagged issues as expected.

Pydantic does some pretty strange stuff which works as expected but confuses the type checker unless you use the pydantic plugin. https://docs.pydantic.dev/latest/integrations/mypy/

I see. Tried ty and it seemed to know about missing required args. But wasn't able to follow the Field directives.

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

#133

Post by JimDabell »

IshKebab wrote: post #117
JimDabell wrote: post #78

Earlier quoted context omitted.

This isn’t. They actually fixed that bug. Then they changed their minds and backed the fix back out again because they don’t think you should write Python that way : > I think EAFP is a very unfortunate and ill-advised practice. They want you to not write the idiomatic Python: try: foo = bar["baz"]["qux"] ... except KeyError: ... …and instead write the non-idiomatic version: if "baz" in bar and "qux" in bar["baz"]: f…

Well I agree with them. The second code is clearly better. Exceptions should be used for error handling and if those keys are actually optional then you should explicitly check if they exist (or use something like `bar.get("baz")`).

You are welcome to that opinion, but type checkers should not be opinionated, especially if they push people to write non-idiomatic Python. If you think this should be written a different way, that’s what lint rules are for.

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

#134

Post by bvrmn »

kstrauser wrote: post #55
phailhaus wrote: post #45

Earlier quoted context omitted.

Python's type system is the problem here, which cannot support even the native dataclass pattern and needs custom plugins written for each type checker.

The type system’s alright. It just gets especially tricky when you’re trying to check code which won’t exist until you run it. For instance, suppose you wanted to load your own module from a database with something like foo = eval(result) It can’t know what you’re going to load until it actually does it. Things which lean heavily into metaprogramming, typically ORMs or things like Pydantic, fall into that category. I…

I guess you didn't work with good type system then. Look for TS, for example. How it allows to make strong typing for pydantic-like libraries in FE world. All how it allows to type routers.

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

#135

Post by bvrmn »

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

Earlier quoted context omitted.

I don't think this is really true, I think native data classes can do just about everything you need, it's just that you need some tooling around them to get the same as Pydantic offers. I'm pretty sure we are going to see better native dataclass support in Pydantic going forward. Already there is some support in Pydantic for native dataclasses: https://docs.pydantic.dev/latest/concepts/dataclasses/

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.

Technically there is dataclass_transform [1]. It's an ungodly hack, I don't know how it passed PEP review. And support by type checkers is questionable. After TS python hints feels like rigid and total unsound mess.

[1]: https://docs.python.org/3/library/typing.html#typing.datacla...

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

#136

Post by scuff3d »

_flux wrote: post #36
giancarlostoro wrote: post #29

Earlier quoted context omitted.

It's funny because in other typed languages a string can be null because of string being a reference type as opposed to a value type. I think Python type hints make more sense than C# does in this respect, which gives me a chuckle (two of my favorite languages and the untyped one makes more sense with types). That said, not sure if you already have but I would add a github issue / ticket reporting your issue to raise…

In some other typed languages, that is. E.g. in C++, OCaml, Haskell, F#, Kotlin, and Rust (a non-exhaustive list) you can have non-nullable strings, and other objects.

In Zig you have to mark variables as nullable when they are declared. If you try to assign null to any variable that doesn't have it marked as such the program won't compile.

Any nullable type has to be unwrapped before accessing the value, or again, won't compile.

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

#137

Post by sh34r »

eqvinox wrote: post #90
notatallshaw wrote: post #81

Earlier quoted context omitted.

I assume in your example if you update the foo declaration to the following it solves the complaint: foo: list[str] = [] If so this a type checking design choice: * What can I infer from an empty collection declaration? * What do I allow further down the code to update inferences further up the code? I don't know Pyrefly's philosophy here, but I assume it's guided by opinionated coding guidelines inside Meta, not wha…

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 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. The fact of the matter is, you declared foo as a list[any] and you’re passing it to a function that takes an iterable[str] — it ought to complain at you! Type hints are optional in Python, and you can tell linters to suppress warnings in a scope with a comment too.

That being said, perhaps these more permissive rules might be useful in a legacy codebase where no type annotations exist yet.

Really, it’d be extra nice if they made this behavior configurable, but I’m probably asking for too much there. What’s next, a transpiler? Dogs and cats living together?!

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

#138

Post by IshKebab »

JimDabell wrote: post #133
IshKebab wrote: post #117

Earlier quoted context omitted.

Well I agree with them. The second code is clearly better. Exceptions should be used for error handling and if those keys are actually optional then you should explicitly check if they exist (or use something like `bar.get("baz")`).

You are welcome to that opinion , but type checkers should not be opinionated, especially if they push people to write non-idiomatic Python. If you think this should be written a different way, that’s what lint rules are for.

Actually Python type checkers must be opinionated. Python doesn't define the semantics of type annotations so type checkers have to choose them.

They don't always choose the same options, so some Python code may type check in one type checker and not in another.

Yes this is a dumb situation but that's how it is. So Pyright has to make a choice here, and they chose the most sensible option.

You're free to disagree of course.

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

#139

Post by pjmlp »

seabrookmx wrote: post #79
giancarlostoro wrote: post #29

Earlier quoted context omitted.

It's funny because in other typed languages a string can be null because of string being a reference type as opposed to a value type. I think Python type hints make more sense than C# does in this respect, which gives me a chuckle (two of my favorite languages and the untyped one makes more sense with types). That said, not sure if you already have but I would add a github issue / ticket reporting your issue to raise…

If you use the nullable types compiler option in C# (which defaults to enabled for new projects) then you need to declare you string as string? for it to be nullable :)

Yes, but you also need to turn the warning into an error for it to be actually usable, because .NET team didn't want to break the ecosystem, plenty of Assemblies out there didn't cared to update themselves.

I still have to disable nullable types in some delivery projects.

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

#140

Post by pjmlp »

dev_l1x_be wrote: post #124
whalesalad wrote: post #15

Python is starting to feel a bit like JavaScript circa 2014. Remember grunt, gulp, webpack, coffeescript, babel? Now we've got pyright, mypy, pyrefly, black, ruff, ty, flake8, poetry, uv... I used to find this kind of tooling explosion exhausting (and back then with JS it truly was), but generally speaking it's a good sign that the community is hungry to push things forward. Choice is good, as long as we keep the Uni…

Is there any meaningful difference between TS and Python?

One uses runtimes that ship a state of the art JIT compiler, whereas the other is only now giving the first steps.

Yes there are alternatives to CPython, unfortunely they aren't adopted as much as they should.

Post reply on HN