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

Pyrefly: A new type checker and IDE experience for Python

engineering.fb.com

Post reply on HN
Print view View original

91–100 of 177 posts

Re: Pyrefly: A new type checker and IDE experience for Python

#91

Post by misnome »

dist-epoch wrote: post #79
doug_durham wrote: post #49

Why is "written in Rust" a feature to be mentioned? Who cares? So my type checker has memory protection and is compiled. I'm not running my type checker on an embedded system or in a mission critical service. It seems kind of like "written in Erlang". I'd prefer to have non-performance critical code for Python written in Python. That way the broader community can support and extend it.

> I'd prefer to have non-performance critical code for Python written in Python A type checker is performance critical code. You can watch how Pylint, just a linter, written in Python, lints your source code line by line. It's so slow it can take 30 seconds to update the linting after you change some lines.

Or entire projects abandoning checking because mypy is so damned slow for anything non-trivial

Re: Pyrefly: A new type checker and IDE experience for Python

#92

Post by mixmastamyk »

mdaniel wrote: post #63
lynndotpy wrote: post #56

Earlier quoted context omitted.

Have you used Rust before? As a user, the speed and safety is nice. But as a developer, Rust projects are easier to hack on and contribute to. That's kind of the whole appeal of Astral. I know Python better than Rust, but it's a lot easier for me to hack on Rust projects. The whole appeal of Astral is that they want to bring Rust-quality tooling to Python.

> but it's a lot easier for me to hack on Rust projects That static typing is nice, I wonder if it's going to catch on one day. The amount of energy spent trying to bend dynamically types languages into being real ones is just comical. Even the standard library is barely typed, so they give no fucks https://github.com/python/cpython/blob/v3.13.3/Lib/re/__init... What does it accept? Who knows. What does it return? Do…

regex.match takes strings and returns a match object. There are most likely stubs, if you are new to it and need support.

Re: Pyrefly: A new type checker and IDE experience for Python

#93

Post by mixmastamyk »

dist-epoch wrote: post #79
doug_durham wrote: post #49

Why is "written in Rust" a feature to be mentioned? Who cares? So my type checker has memory protection and is compiled. I'm not running my type checker on an embedded system or in a mission critical service. It seems kind of like "written in Erlang". I'd prefer to have non-performance critical code for Python written in Python. That way the broader community can support and extend it.

> I'd prefer to have non-performance critical code for Python written in Python A type checker is performance critical code. You can watch how Pylint, just a linter, written in Python, lints your source code line by line. It's so slow it can take 30 seconds to update the linting after you change some lines.

Many of these make the mistake of running against an entire codebase instead of checking vcs first and only running against changed files.

Re: Pyrefly: A new type checker and IDE experience for Python

#94

Post by mixmastamyk »

dontlaugh wrote: post #59
WhyNotHugo wrote: post #55

Earlier quoted context omitted.

> 1. Maybe it's time to drop the crazy runtime generation and have something statically discoverable, or at least a way to annotate the typing statically. That, and duck typing, are one of the biggest things that make Python what it is. If I have to drop all that for type checking and rewrite my code, why would I rewrite it in Python?

Having used Python for many years, it’s the least interesting aspect of the language. Almost all such tricks can be done with compile time meta programming, often even without API changes.

I'd like to read a blog post on this subject, if anyone knows one.

Re: Pyrefly: A new type checker and IDE experience for Python

#95

Post by artemisart »

oellegaard wrote: post #82

I lost all interest when I saw VS Code. I don’t get why people consider this a suitable IDE for python when you can have a real IDE like PyCharm.

pyrefly is not tied to vscode? Also please try to be more considerate of people preferences, and pycharm is not strictly better. Remote dev on vscode is very convenient for me, should I go on the Internet saying that pycharm is trash? No

Re: Pyrefly: A new type checker and IDE experience for Python

#96

Post by rafram »

lynndotpy wrote: post #56
doug_durham wrote: post #49

Why is "written in Rust" a feature to be mentioned? Who cares? So my type checker has memory protection and is compiled. I'm not running my type checker on an embedded system or in a mission critical service. It seems kind of like "written in Erlang". I'd prefer to have non-performance critical code for Python written in Python. That way the broader community can support and extend it.

Have you used Rust before? As a user, the speed and safety is nice. But as a developer, Rust projects are easier to hack on and contribute to. That's kind of the whole appeal of Astral. I know Python better than Rust, but it's a lot easier for me to hack on Rust projects. The whole appeal of Astral is that they want to bring Rust-quality tooling to Python.

Rust has very arcane syntax and a lot of rules that developers coming from interpreted / garbage-collected languages (like the ones using these tools) would have a hard time grasping. It’s easy for people who are already familiar with it, but isn’t that always the case?

Re: Pyrefly: A new type checker and IDE experience for Python

#97

Post by oellegaard »

artemisart wrote: post #95
oellegaard wrote: post #82

I lost all interest when I saw VS Code. I don’t get why people consider this a suitable IDE for python when you can have a real IDE like PyCharm.

pyrefly is not tied to vscode? Also please try to be more considerate of people preferences, and pycharm is not strictly better. Remote dev on vscode is very convenient for me, should I go on the Internet saying that pycharm is trash? No

I’m not saying VS Code is trash but I think it’s closer to a text editor than an IDE. I even use it for some things non python but I remain curious to the fact why people use it for python.

It might not be tied to VS Code but the title clearly says “New […] IDE experience for…” which is why I commented. I had hoped to see something for PyCharm or even a new IDE.

Re: Pyrefly: A new type checker and IDE experience for Python

#98

Post by simonw »

baggiponte wrote: post #14
simonw wrote: post #7

Earlier quoted context omitted.

ty is so new right now - it only got its current name a few weeks ago!

That’s not true, they have been developing it as red knot for a good while :)

Like I said, it only got its name a few weeks ago.

Re: Pyrefly: A new type checker and IDE experience for Python

#99

Post by mdaniel »

mixmastamyk wrote: post #92
mdaniel wrote: post #63

Earlier quoted context omitted.

> but it's a lot easier for me to hack on Rust projects That static typing is nice, I wonder if it's going to catch on one day. The amount of energy spent trying to bend dynamically types languages into being real ones is just comical. Even the standard library is barely typed, so they give no fucks https://github.com/python/cpython/blob/v3.13.3/Lib/re/__init... What does it accept? Who knows. What does it return? Do…

regex.match takes strings and returns a match object. There are most likely stubs, if you are new to it and need support.

This response highlights both parts what I was saying: it's not just strings, and "I'm sure there's some extra things that the standard library wants you to duct tape together, good luck"

Re: Pyrefly: A new type checker and IDE experience for Python

#100

Post by mixmastamyk »

mdaniel wrote: post #99
mixmastamyk wrote: post #92

Earlier quoted context omitted.

regex.match takes strings and returns a match object. There are most likely stubs, if you are new to it and need support.

This response highlights both parts what I was saying: it's not just strings, and "I'm sure there's some extra things that the standard library wants you to duct tape together, good luck"

It is exactly two strings that are required. The docs are there for flags etc, use them. Types were not entered directly into stdlib source for historical reasons.

If you would enjoy further support, install stubs from typeshed.

Post reply on HN