161–170 of 181 posts
Earlier quoted context omitted.
Ruff wasn't named after the bird, we just think it's funny that Charlie didn't know it was a bird. He made up the word :)
I've always assumed it was something like: ruff - "RUst Formatter". ty - "TYpe checker" uv - "Unified python packaging Versioner"? or "UniVersal python packaging"
Earlier quoted context omitted.
> but pyright will not (because it infers the types of unannotated collections as having Any) This is incorrect. pyright will infer the type of x as list[Unknown].
Unknown has the exact same type system semantics as Any. Unknown is a pyright specific term for inferred Any that is used as the basis for enabling additional diagnostics prohibiting gradual typing. Notably, this is quite different from TypeScript’s unknown, which is type safe.
I've never really felt the existing options were lacking for our use case. Completely fair game if this was just a passion project, but at this point at best this feels like noise, at worst some overzealous developer is going to implement this in my teams pipeline and waste time. Waste his time because the existing type checker did the job and there was not reason to change it, and waste our time because they will likely change (probably tighten) the existing behavior and waste our time while we adapt our habits to it.
Hopefully it gets added to this comparison: https://htmlpreview.github.io/?https://github.com/python/typ... If that table is anything to go by, Pyright is not to be underestimated. I have briefly tried ty (LSP) in Emacs and it seems to work well so far. The only questionable thing I've encountered is that when the signature of a method is shown, the type annotations of some parameters seem to be presented in a partic…
Pyright is really really good. Anyone that doubts that 10x engineers exist, just go and look at Eric Traut. He's pretty much written it single handedly. Absolute machine. Mypy is trash. Nice to have a table to point to to prove it.
The problem is that the conformance tests were mostly written by Eric Traut, so there's a natural bias towards specifying what Pyright does well. There's a lot of things Mypy does really well that should probably be implemented in Pyright.
Without digging too deep- what is the Django story? Django does a bunch of magic which is challenging for the type checkers to handle well.
Too bad they did not benchmark Zuban, which is also promising. Also, it's also too bad we have three competing fast LSP/typechecker projects now We had zero 1 year ago.
The guy behind Zuban should've put his project out the in open way earlier. I'd love to see both projects succeed, but in reality it should become one.
It might not be used as much, but to be honest I think that's fine. I'm not a big VC-funded company and just hope to be able to serve the users it has. There's space for multiple tools in this area and it's probably good to have multiple type checkers in the Python world to avoid the typical VC rug pull.
Earlier quoted context omitted.
> And the fact that python doesn't specify the semantics of its type annotations is a super interesting experiment. That hasn't been a fact for quite a while. Npw, it does specify the semantics of its type annotations. It didn't when it first created annotations for Python 3.0 (PEP 3107), but it has progressively since, starting with Python 3.5 (PEP 484) through several subsequent PEPs including creation of the Pytho…
So why do the type checkers differ in behavior?
Edit: +"then try again"
Earlier quoted context omitted.
You're not wrong, but a) most of the badness happened after the founders checked out and b) it's hard to find examples of developer tool companies doing better.
You however, are. Hashimoto didn't leave until December 2023, Hashicorp announced the license change August 10, 2023. Also way back in September 2021 they started having staffing issues and stopped accepting community contributions, and also made the questionable choice of going public that same year. You might be on to something with point B, hard to find good examples of developer tool companies that don't eventual…
As for "slapping a company on it", I agree, but also I don't think we've developed a viable alternative. Python has been limping along with one toolchain or another for my entire career (multiple decades) and it took Astral's very specific approach to create something better. It's fair to ask why they needed to be venture backed, but they clearly are and the lack of successful alternatives is telling.