I love the speed advantage of pyrefly over (based)pyright but so far it doesn't seem to highlight as much as pyright does, for example it doesn't catch unreachable code like this:
def fn(x: str):
if x is None:
x = "123" # pyright flags that as unreachable code, pyrefly does not
Autocomplete for modules also doesn't work for me yet:
import os
os. # I'll get `ABC, `Any`, `AnyStr`, `AnyStr_co`, `BinaryIO`, ...
Looking forward to have a fast language server for python though, pyright is way too slow for large projects.
Hey, Pyrefly developer here, thanks for trying us out! Thanks for bearing with us with these issues you're experiencing while we're still in alpha.
We're planning on adding unreachable code diagnostics soon (github issue [here](https://github.com/facebook/pyrefly/issues/1292)). These come for free with Pyright so we don't want to regress features.
I'm happy to help diagnose/fix your autocomplete issue: it should work on modules. If you want to provide details here, on [discord](https://discord.gg/Cf7mFQtW7W), or as a Github issue (github/discord preferred) we'll fix it for you + anyone else with the problem.
I absolutely understand this is still alpha so I kind of assumed these are expected. Frankly, that's why I haven't submitted an issue -- I assumed it's going to be fixed at some point. I'll go ahead and make an issue on GitHub, thanks.
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 awareness to the devs.
A quibble: Python is strongly typed. It’s not un-typed in any reasonable sense of the word. It’s dynamically typed, though: type information is on objects, not on the names referring to them.
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.
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.
It’s worth noting that even though the runtime allows nulls (i.e. None) anywhere, Python type checkers do distinguish between optional and mandatory types.
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.
It's not valid from a typing perspective, but python will let you. If you want to disregard types though then none of this matters anyway and you won't get much benefit from these tools
Ty has autocomplete for imports, but it's hidden behind a toggle right now. They are still working on it. They index all the modules and functions, so you can just type the function name and it will suggest the correct import and insert it.
I'm working on Penteglot - a fork of Emacs's Eglot LSP client with multi-server support.
The main feature: you can run multiple language servers simultaneously for the same buffer.
One of the main reasons people stick with lsp-mode over Eglot has been the lack of multi-server support. Eglot is otherwise the most "emacsy" LSP client, so I'm working on filling that gap and I hope it could be merged into Emacs one day.
This is still WIP but I've been using it for a while for Python (basedpyright or pyrefly + ruff for linting) and TypeScript (ts-ls + eslint + tailwind language server).
Not sure why are you getting downvoted but I wanted to express my appreciation of comments like this. Being a non-native speaker I’ve been struggling with nuances like that one and native speakers I encounter hardly ever want to correct my errors, likely because they don’t want to come across as rude.
Adding a support for direct CDP connection with our custom browsers cluster that powers our web scraping API (https://scrapingfish.com/) so that our customers can integrate it into their existing workflows.
Interesting question to me, as I was focusing on AI for most of my career but got burnt out. Getting back to more traditional software engineering was a bliss. Right now, I'm working on our web scraping API SaaS (https://scrapingfish.com/). What I found mildly surprising and amusing is how web scraping happens to have one common thing with AI: you hypothesize on something, run an experiment, draw conclusions, iterate.
I generally quite enjoyed the podcast but I found it a bit weird how in the episode about the Aztecs the author was so adamant to call them by their actual name that the ‘Aztec’ people used themselves. However he had no issue at all with the Byzantine Empire/Byzantines etc and continued using these term throughout the entire episode.
A SaaS we developed with my cofounder. Started at the beginning of this year and been growing steadily. We are involved daily in user support, marketing and development.
We attribute the growth to a couple of very successful blog posts which made it to the front page of HN.
I love that eglot is being incorporated into emacs, though I myself use lsp-mode. Does anybody know how advanced eglot is? As far as I hear, it doesn't support multiple language servers which seems like a showstopper for web dev these days, e.g. I usually have ts lang server + tailwind lang server running at the same time when doing web dev.
As far as out-of-the-box support, I think it works great. Much easier to configure than lsp-mode.
However, for my uses with a Ruby/React+TSX setup the performance was lacking on a large codebase. I swapped back to lsp-mode and the experience felt smoother.
IIRC the author's stance on previous discussions around multiple language servers was to rely on flymake instead, since the previous discussion centered around ESLint + TypeScript. Tailwind is a bit of an issue in the ecosystem right now, but you may want to try https://github.com/merrickluo/lsp-tailwindcss.
Have you tried emacs-plus[1]? That's what I've been using for years now on macOS and never ran into issues. Opening big files is a different topic though I believe it doesn't work much better on Linux too.
