Document `all` option of `typeCheckingMode`

[lucaspar]

The new all option of typeCheckingMode doesn't seem to be documented.

• What is the difference between all and strict?

Another matter related to that: the original default was standard; but if all is even more comprehensive than strict, what was the reasoning behind making it the default? My concern is that this would make basedpyright overly pedantic, and that might not be a good default behavior. Both due to false positives and for reducing the noise, especially when working on existing code bases.

[DetachHead]

• What is the difference between all and strict?

"strict" has most rules enabled but not all of them, which is unchanged from the upstream behaviour. we also don't enable any of our additional rules in strict mode. this makes it easier for users who just want basedpyright to act the same as pyright.

Another matter related to that: the original default was standard; but if all is even more comprehensive than strict, what was the reasoning behind making it the default? My concern is that this would make basedpyright overly pedantic, and that might not be a good default behavior. Both due to false positives and for reducing the noise, especially when working on existing code bases.

the motivation behind the decision to make it the default is documented here, but i'll expand on it a bit as it's something i feel very strongly about.

i think it's a huge waste to develop all these checks and turn them off by default, because most users will install a tool and stick with whatever the default settings are, being completely unaware that there are many more checks that they can have on their code, often ones that they would have enabled if they knew about them.

i know it can be daunting to install a new tool and be bombarded with thousands of errors, which is why we want to add baseline support to help address this concern (#2).

i'm confident that enabling all the rules by default is the best approach, because it forces users to make a conscious, informed decision about exactly which checks they want enabled in their project. several users, myself included, have learnt a lot about python because of this.

you wouldn't want to buy a car with the airbags secretly disabled by default, but that's what most linters and type checkers do and i find it absurd. pylance for example recently took it a step further and disabled all of the type checking by default, when previously it was set to "basic". i wholeheartedly disagree with this approach, but as long as users have the option to disagree with my approach (just change typeCheckingMode to something else), i don't see an issue with the current behaviour

[KotlinIsland]

I wonder if there is any value in a setup wizard that would walk through various options (library/application, python version/platform etc), explain the defaults and new based rules, and facilitate creating a config file

[lucaspar]

@DetachHead thanks for clearing it up.

Many industries have the concept of alarm fatigue, and it's something very real: warnings and safety checks being ignored or preemptively disabled due to their frequency. Baseline might indeed help with it when adopting more strict checks into projects, but until then I'm using standard in most projects.

[DetachHead]

thats a good point, alarm fatigue is also something i'm very conscious about (i didn't know it had a name lol). my experience with it is that users tend to brush off errors if they occur in their IDE but not in the CI, ie. an error that won't actually stand in the way of their code being merged.

for example, pycharm's built in type checking is awful and has so many false positives (and false negatives) that users just ignore the errors entirely and just rely on the errors from pyright or mypy that occur in their CI. i think having most checks disabled by default is not addressing the root problem which is errors that occur in their IDE which are not "real" errors and therefore they assume it's not something worth worrying about.

this is an issue i've encountered with every project i've ever tried work on, which is why i always make sure to commit IDE config files to ensure that contributors get the same checks in their IDE as the CI.

[KotlinIsland]

Are you finding false positives/negatives with basedpyright? Or are you perhaps referring to the Any banning rules?

[DetachHead]

closing this for the reasons in my previous comments. if you disagree feel free to comment and we can re-open this issue and discuss further