search

KotlinIsland / basedmypy

Based Python static type checker with baseline, sane default settings and based typing features
https://kotlinisland.github.io/basedmypy/
Other
144 stars 4 forks source link

mypy compatibility mode #788

Open KotlinIsland opened 1 week ago

KotlinIsland commented 1 week ago

@jorenham any suggestions?

jorenham commented 1 week ago

So the goal would be to have a --compat flag or something, that, when enabled, would ensure that if it passes basedmypy, it also passes mypy. Or in other words, a guarantee that basedmypy is a (strict) superset of mypy. Did I get that right?

The first thing that comes to mind would be to get an overview of what currently isn't, or might not be, backwards compatible with mypy. If it's only limited to typeshed, then this such a compatibility mode would be a piece of cake. But if there are other cases where basedmypy reports a true negative, where mypy would report a true positive, then, those basedmypy features will have to be disabled within the compat mode, as well.

KotlinIsland commented 1 week ago

being 100% compatible with mypy sounds impossible and not actually all that beneficial. I think a practical approach would be something like: public interface is 484 compatible

or would it be a concern that not only is the public interface standard, all internal mechanisms are consistent with how mypy specifically works, such that reverting back to mypy would be simple?

jorenham commented 1 week ago

Making it easy to revert back to mypy would indeed be helpful. The main concern is that by using basedmypy, that there could be cases where some new code passes in basedmypy, but mypy reports it as an error. Because for our users, that could lead to backwards-incompatible typing issues that we weren't able to warn them about beforehand.

So in other words, we don't want situations where basedmypy says "ok", but mypy says "error", at least now without us knowing about it.

However, if such a reported mypy error is directly caused by a confirmed mypy bug (i.e. a false positive), and that bug is already fixed in basedmypy in a way that conforms to the typing spec, then I think that it shouldn't be much of a problem. But even so, it would be better if we could know about beforehand, which is currently difficult because basedmypy and mypy both use the mypy package name, which makes it very difficult to type-test with both.