Attractive females might also have different behavior in remote teaching. Attractiveness directly affects how people behave and feel. This might also be different for males vs. females.
I'm sure that attractiveness does play a role for grades, it's just not nearly as simple as the paper puts it.
There are a lot of potential explanations, which is why these kinds of studies are unfortunately not that helpful and often cause questionable media coverage.
Zuban maybe doesn't succeed in terms of the amount of users, but it's nearly finished, supports the full Python type system (I'm in the process of completing the conformance tests), has support for Django and LSP support is also pretty much complete. So in a technical way it did already succeed.
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.
Zuban continues to have "not great" diagnostics like the rest of the python type checkers, where ty has "rust inspired" diagnostics that are extremely helpful. It's a shame to hear that the current state is considered "nearly finished".
Have you tried `--pretty`? That is more of a Rust style. Most type checker report the short version, but have longer versions of the issues. IMO that's a good choice, but opinions might differ.
Mypy is not trash at all. It is still the most precise type checker, supports a lot of complicated cases and has plugins that make a lot of things more type safe. I believe Mypy is severely underrated and a lot of people believe that it's not as good as Pyright because of the conformance tests.
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.
Most people will be using it as an LSP in their editors. Some companies might be interested in creating services on top of it. They won't be hosting the LSP, but they might want to use it to index code. And at that point there's at least some way for monetization.
Due to AGPL's viral nature they will have to open source their code if they use it as a library. But in general I feel like companies simply don't want to deal with the potential "threat" of lawsuits so they don't want to use it that way. This means they either search for other solutions or will try to negotiate some kind of deal.
It was originally designed to be used by government software in the EU. AFAIK, it doesn't really get used for much else, but it fills a niche not covered by the GPL family, which is weak/non-viral copyleft (as the LGPL provides), plus handling SaaS in a reasonable way (as the AGPL provides).
Copyleft protects against proprietary forking, and also assures the community you can't close the source in the future. Weak/non-viral copyleft makes it so you can still link it to proprietary software, so you could sell integrations (non-LSP) or closed-source plugins.
LGPL and GPL licensed software can be provided over a network with proprietary changes. The AGPL and EUPL both close that hole. Every change to the modules covered by the EUPL must be open sourced, even in that case.
If your intention is to monetize the LSP itself, open source is probably not what you want. It's fundamental to open source that anyone can use it for any purpose, and also fork it. Permissive licenses like the MIT license allow relicensing to a proprietary license later (see Redis) but that causes problems with the community (see Redis), and is nearly guaranteed to cause a fork.
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 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).
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.
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.
I'm sure that attractiveness does play a role for grades, it's just not nearly as simple as the paper puts it.
There are a lot of potential explanations, which is why these kinds of studies are unfortunately not that helpful and often cause questionable media coverage.