281–290 of 296 posts
Not the most fun question, but as I see Astral taking over the python ecosystem, I can't help but wonder: how do y'all plan to make money? It seems like you've taken VC funding, so monetization is inevitable.
Earlier quoted context omitted.
mypy is compiled using mypyc. It does not run as Python code.
The semantics of Python makes it problematic to run at speed, it is not just about interpreted vs compiled code. Give the high levels of dynamic behaviors that are allowed, a Jit (like pypy) has a higher chance of getting decent performance if the code has an underlying behavior that can be extracted.
Earlier quoted context omitted.
This argument doesn't make a whole lot of sense because nothing about type annotations constrains Python code at all. In fact because they're designed to be introspectable they make Python even more dynamic and you can do even crazier stuff than you could before. Type checkers are working very hard to handle the weird code. Pydantic being so fast because it's written in Rust is a good thing, you can do crazy dynamic…
> nothing about type annotations constrains Python code at all Sorry, but this is just not true. Don't get me wrong, I write typed Python 99% of the time (pyright in strict mode, to be precise), but you can't type check every possible construct in the language. By choosing to write typed Python, you're limiting how much of the language you can use. I don't think that's a bad thing, but it can be a problem for untyped…
Earlier quoted context omitted.
I agree that would be nice; probably not near the top of our list right now (and not trivial to implement), but it makes sense. Thanks for the suggestion.
Nontrivial way to do it is dynamically scan the python 3.12 namespace, and add these warnings. Is there any big downside to do it the boring way, hardcode a list and compare the error to the list?
Earlier quoted context omitted.
How is it condescending in any way? I found it to be a constructive criticism; i.e. useful help.
I don't necessarily read it as condescending, but I do read it as presumptuous. What someone "should" do depends on many things. Maybe, because this is software in alpha stage, they should _not_ focus on this part of the code if it is minor compared to other obligations. Or maybe there are other reasons they've chosen not to do this (as was explained in an above comment). IMO, a less presumptuous criticism would be p…
Earlier quoted context omitted.
Great, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast. https://github.com/microsoft/pyright
I don't get why so many people go to bat for pyright, my experience with it has been pretty miserable. Open enough instances of it and you're in OOM city. It works, but often gets confused... and of course the absolute audacity of MSFT to say "let's go over to pyright, and by the way we're going to carve up some stuff and put it into pylance instead", meaning that it's totally not within the actual spirit of open sou…
Earlier quoted context omitted.
I tested it side-by-side on my ~100Kloc codebase. Ty: 2.5 seconds, 1599 diagnostics, almost all of which are false positives Pyright: 13.6 seconds, 10 errors, all of which are actually real errors There's plenty of potential here, but Ty's type inference is just not as sophisticated as Pyright's at this time. That's not surprising given it hasn't even been released yet. Whether Ty will still perform so much faster on…
Compilation / type checking depends on a lot of trees of typed data, and operating on those tree nodes. That's something where a statically typed language with custom data structures that allows for optimised representations makes a big difference, and where a lot of the fancy optimisations in v8 don't work so well. There is a reason Typescript moved to a typed language.
Curious why so many people want to implement type checkers for python? What problems are being solved that aren't covered already?
Earlier quoted context omitted.
I don't get why so many people go to bat for pyright, my experience with it has been pretty miserable. Open enough instances of it and you're in OOM city. It works, but often gets confused... and of course the absolute audacity of MSFT to say "let's go over to pyright, and by the way we're going to carve up some stuff and put it into pylance instead", meaning that it's totally not within the actual spirit of open sou…
If you haven’t checked it out already, basedpyright is pyright with all the arbitrarily carved out functionality put back in – plus some extra features that you may or may not find useful depending on how strict you like your typing. Can’t recommend it enough