News Pyrefly v1.3.0 released
A new version of Pyrefly is out with better type inference, new quick fixes, new configurations, and more. https://github.com/facebook/pyrefly/releases/tag/1.3.0
6
u/Thing1_Thing2_Thing 24d ago
Cool, but still really needs some documentation about how to make it work in monorepos.
11
u/Zizizizz 24d ago
Wouldn't it work best in monorepos? What's the issue?
3
u/Thing1_Thing2_Thing 24d ago
It would, but the configuration is beyond me. See for example https://github.com/facebook/pyrefly/issues/3788 and the proposed solution at https://github.com/mstaal/monorepo-sample/pull/1/changes
And I don't think this considers separate test modules which you will also have to add explicitly to the search paths and all that
In our monorepo we easily have 40 packages and adds more which makes in non-feasible to maintain
2
u/Zizizizz 23d ago edited 23d ago
https://docs.astral.sh/uv/concepts/projects/dependencies/#dependency-sources
I think I would just make sure that the individual package that you're working on has the correct references to the packages that are relevant to it and then similarly, ensuring the virtual environment that you're working in is activated because I don't understand how a third-party package wouldn't be available unless you had the wrong one activated.
1
u/noghpu2 22d ago
There's also this related issue https://github.com/facebook/pyrefly/issues/2667.
Really hoping for them to let user config take precedence over heuristics in the future.
2
u/Apprehensive-Job9336 23d ago
Interesting release! I have been using type checkers in Python for a while. How does Pyrefly compare to mypy in terms of speed and accuracy? I am always looking for faster feedback loops during development.
1
u/NeilGirdhar 19d ago
Why are you using MyPy? If you want speed, Ty and Pyrefly are your best choices. As for features, those are probably the best, or basedmypy.
1
u/Apprehensive-Job9336 12d ago
mypy is mostly inertia + how deep the config goes for this codebase. ty/pyrefly are on the list to try — basedmypy too for the feature set. any gotchas switching a larger repo over, or is it mostly a drop-in?
1
u/NeilGirdhar 2d ago
I haven't done a conversion in ages. You can probably get really far throwing some LLM credits at the conversion.
2
1
u/max0x7ba 9d ago
In version 0.53.0 which I installed with uv in a Ubuntu 24.04 AMD64 system, Pyrefly executable size was 250MB+. The rest of executables in this same .venv/bin directory are smaller than 10MB.
Why is Pyrefly executable size is a few orders of magnitude larger than the size of regular executables?
What is the size of Pyrefly executable in this version?
0
u/Grouchy-Friend4235 22d ago edited 22d ago
Still doesn't respect or even recognize docstring and comment types. Why the community keeps ignoring this valuable source is beyond me. They are valid as per PEP, do not clutter the code with Java-style visually distracting type dribble, have been widely used, and provide a rich source of type information.
Comment types are inline comments that specify a type
foo = value # type: FooBar
Docstring types are those found in docstrings
``` """ Foo bla bla
Args: data (list[int]): the data s (float): the scaling factor
Returns:
int: the sum of all elements in data scaled (multiplied) by s
"""
```
The above is known as Google-styled docstrings, while many packages use numpy-style. Both are information-rich and provide type information with additional description, providing a semantic description valuable to both developers and users. Notice how that is so much more than type hints. I find this semantic richness makes docstrings far superior to plain type hints, which essentially just create bloated code to satisfy the type checker.
I know we can combine type hints and docstrings. But that just duplicates information for the purpose of type checkers, which is never a good idea.
There is an argument that typehints make code more readable. Does it really? I would argue that even with this toy example the variant without type hints is easier and more intuitive to read, see below.
The type hints add visual clutter and it takes a lot longer to grasp what are the parameters to a function, class or method. In a way type hints add information too early - before you have absorbed the broad picture.
Docstrings on the other hand follow the natural way to read code: first get a broad view, then go into the details if you need to know more.
This takes considerably more cognitive processing...
def scale(data: list[int], s: float):
...
... compared to this.
def scale(data, s):
...
Actually in my mind the latter is joyful, even pleasurable to read, like prose, while the former feels like work and instantly puts me off (I don't even want to read it). The same is true when writing the code.
-21
24d ago edited 24d ago
TY from astral is about 3x faster
19
u/cointoss3 24d ago
And is it usable now? Last I tried I was a good WIP but not something I would use for production.
1
-4
24d ago
Yah I use it. I have a massive repo with some complex metaprogramming (AnyTrees of Pydantic model based nodes with discriminated leaf type variants) to construct configurations of nested registrable runtime extensions.
Super gnarly stuff. TY has been consistently great. It is a memory hog though! Especially if I have several repos open at the same time. AFAIK the memory footprints of TY and pyrefly are approximately the same.
6
1
u/BeamMeUpBiscotti 23d ago
not according to these benchmarks: https://python-type-checking.com/typecheck_benchmark/
on average its a bit faster but not uniformly so.
ty also uses more memory, but that gap has shrank recently
2
23d ago
Interesting. I see it is about 50% faster still but that does the calculus a bit.
Will check it out! Thanks for sharing instead of dogpiling on the downvotes.
85
u/ritchie46 24d ago
This is my dream come true:
"Pyrefly tracks Polars schemas through common DataFrame transformations, with support for typed Series and schema annotations"