It's great to see so much innovation in this area. But, seeing that you will charge for this - what will you provide that won't be covered by free alternatives in e.g. Ty (Astral) or Pyre (Meta), which similarly seem to be "mypy but in rust and maybe lsp features"?
davidhalter 2 hours ago [-]
If I'm perfectly honest, I don't know yet. I'm currently pretty open to any model that ensures long-term survival of the project. Some people might be interested because it can be used as a replacement for Mypy and I'm willing to solve the issues they have in their 1mLoC+ codebases. It is absolutely non-trivial at this point to replace Mypy with Pyright or vice-versa in a larger codebase.
drcongo 5 hours ago [-]
Last time I tried ty and pyre they weren't particularly great with a Django codebase, I'm sure ty will get there at some point, but if this handles django-stubs without any extra faffing, that's one potential selling point.
I did have the same thought as you at first though, and only carried on reading when I spotted that it was from the author of Jedi.
davidhalter 2 hours ago [-]
Django compatibility could definitely be a selling point, but I haven’t built a dedicated Django plugin yet. Right now, I’m prioritizing features like auto-completion and go-to-definition, which I think are more impactful in the short term.
The thing is, both Ty and PyreFly aren’t really close to the level of Mypy or Pyright — neither in terms of features nor stability. ZubanLS already covers the important features, though there are still some bugs I’m working through. So in that sense, yes: At the moment the selling point is that it just works.
Grikbdl 5 hours ago [-]
Both ty and Pyre are in development, so maybe the answer is just "this works and they don't". But they do promise to work eventually, like end of year if I recall correctly. I don't know what makes Django special in this regard though - is it the ORM models that don't work well with the typing spec or..?
davidhalter 1 hours ago [-]
I'm still thinking about a good model for the future, because I know that in the future they will be fine type checkers. I think the biggest advantage I have is that I don't burn big sums of money while doing it, so I only need a modest income. I think my current proposal would be a very fair way to make money. But I also see that this might not work if the competition offers everything for free and open source.
The ORM models do not work with typing at all, you basically have to make a lot of magic work if you want to support it in a type checker (especially if you want to work with reverse foreign keys). Generally type checkers do not just support the Django ORM. For Mypy there's a plugin that works pretty well, but uses runtime information, which further slows down Mypy.
zem 1 hours ago [-]
it's that django does metaprogramming that cannot be expressed in terms of python's static type annotations. you need dedicated plugins that essentially replicate that metaprogramming to generate the relevant types.
it's not just django btw, pretty much any metaprogramming library needs that sort of custom support, including dataclasses - take a look at any python type checker and you will find code specifically replicating what dataclasses does in terms of code generation. for pytype we actually put dataclass and namedtuple support alongside our other third-party plugins in the codebase.
ehutch79 4 hours ago [-]
There's a lot of magic in Django, and yes that's particularly around the ORM.
The foreign key stuff and missing reverse relations in types a big issue, but there's other stuff like warning about class Meta: being incompatible because you're inheriting an abstract model.
I'm yet to find a good guide on how to handle typing a django project, even if only to get vscode to do autocomplete.
drcongo 4 hours ago [-]
I don't know anywhere near enough to answer that with any confidence I'm afraid. I'd like to hear op's opinion though.
dcreater 4 hours ago [-]
Any reason to use and pay for this instead of pyrefly and ty?
(Relative maturity wouldn't be a good enough reason as those projects will progress quickly enough and both have great, solid, well backed teams behind them)
davidhalter 1 hours ago [-]
I think you underestimate how hard it is to move from Mypy to Pyright in big codebases. Having something very very close to Mypy should be very interesting for some companies with 1mLoC+. Relative maturity can still be a reason for 1-2 years and I have no idea what to do at that point.
Relative maturity can be a reason for quite a while (people overestimate how far Pyrefly and Ty are).
zem 1 hours ago [-]
nice work! what level of type inference do you do on unannotated code?
davidhalter 44 minutes ago [-]
Currently none, but I'm currently re-implementing the Jedi part (auto-completions/goto), which needs lots of type inference on unannotated code. There will therefore be soon be a non-compatible mode that infers unannotated code as good as possible. I hope it is going to be ready a month from now.
I did have the same thought as you at first though, and only carried on reading when I spotted that it was from the author of Jedi.
The thing is, both Ty and PyreFly aren’t really close to the level of Mypy or Pyright — neither in terms of features nor stability. ZubanLS already covers the important features, though there are still some bugs I’m working through. So in that sense, yes: At the moment the selling point is that it just works.
The ORM models do not work with typing at all, you basically have to make a lot of magic work if you want to support it in a type checker (especially if you want to work with reverse foreign keys). Generally type checkers do not just support the Django ORM. For Mypy there's a plugin that works pretty well, but uses runtime information, which further slows down Mypy.
it's not just django btw, pretty much any metaprogramming library needs that sort of custom support, including dataclasses - take a look at any python type checker and you will find code specifically replicating what dataclasses does in terms of code generation. for pytype we actually put dataclass and namedtuple support alongside our other third-party plugins in the codebase.
The foreign key stuff and missing reverse relations in types a big issue, but there's other stuff like warning about class Meta: being incompatible because you're inheriting an abstract model.
I'm yet to find a good guide on how to handle typing a django project, even if only to get vscode to do autocomplete.
(Relative maturity wouldn't be a good enough reason as those projects will progress quickly enough and both have great, solid, well backed teams behind them)
Relative maturity can be a reason for quite a while (people overestimate how far Pyrefly and Ty are).