execution environments allow you to use different diagnostic settings on different parts of your project. however i'm not quite sure what you mean by applying different rules to third party packages.

are you type checking 3rd party code or your own stubs for third party code? or are you saying that you want for example the reportAny rule to not be reported on anything that comes from the pandas module?

or is the problem just that you want the strict type checking but don't want to have to fix thousands of errors in old code? if so, you may be interested in the baseline feature that i just released

Sorry for not being clear in the original post.

execution environments allow you to use different diagnostic settings on different parts of your project. however i'm not quite sure what you mean by applying different rules to third party packages.

Execution environments are a great feature that we'll definitely make use of (for example, to relax typing on our test code where I've seen, for example, some aspects of MagicMocks run up against Any-related rules, but not what I mean here.

or are you saying that you want for example the reportAny rule to not be reported on anything that comes from the pandas module?

Yeah, that's kind of what I'm getting at. I'd like to be able to apply strict rules to my own code (and compatible 3rd party libraries), but apply a different set of rules to pandas, for example.

In most cases, this isn't necessary as if the inline typing or stubs for a 3rd party package are insufficient, we can make our own. However, pandas is different because of the complexity of the stubbing (complex enough that pandas team has come out and said they'll never support fully strict pyright typing. So I'd like to be able to be able to, I guess, ignore certain rules for symbols that originate from a particular module.

interesting idea. i'm not famiar with pandas though so i'm curious to see some examples of why it can't be fully typed

i've seen similar scenarios, some things are Any, but are either untypable, or have no bearing on the semantics of the program

the ability to ignore certain Any would be good I think

i guess reportUnknown* vs reportAny covers that

interesting idea. i'm not famiar with pandas though so i'm curious to see some examples of why it can't be fully typed

I don't completely understand the ins and outs of it but I think it's just that the way data types can be changed/defined in series/dataframes would be difficult to type out explicitly. For example, if I have a dataframe with a str, int and datetime-valued columns, I'd need to incorporate that into the typing in a very verbose way so that when I dereference a column, I get back the right Series[?] generic subtype. This is probably just a surface level explanation of the problems pandas would have with pyright strict typing.

pandas skirts around this by just ignoring the type parametrization of the generics - so that e.g. every Series ends up as a Series[unknown] (effectively a Series[Any]). In their own typing they use basic typing but then enable a bunch of extra rules to go partway to strict, and without some package/module-specific rule sets, any project importing pandas is bound to this ruleset as an upper bound (maybe not quite as you may not intersect with the parts of their interface that break certain rules, but that's hard to distinguish and you'll definitely hit some of them no matter what).

Now imagine you have multiple projects with their own subset of strict compliance - you're currently effectively bound to either an intersection of their compliance, or to use a lot of #pyright: ignore[...] directives.

Just my couple thoughts here:

It is, unfortunately, somewhat common that many libraries don't satisfy not just basedpyright's strict mode, but actually don't satisfy any mode that you can reasonably run with. I've run into multiple examples recently after adopting basedpyright. Some examples:

• Beanie - https://github.com/BeanieODM/beanie/blob/main/beanie/odm/fields.py#L82 means I can't import Indexed or it gets flagged? Or I can, but then pyright no longer makes sure all contributors maintain the typing parity and such.

• Do you know why this does not satisfy any rules? Yeah...

These libraries are pretty strongly typed by the way (especially Beanie since it relies on pydantic and stuff)

The issue is that these "problems" usually don't even mean anything, you often have to suppress them, and then suppress real problems with your code etc.

TL;DR I would really want to see an option to disable the upstream problems 😊

The issue is that these "problems" usually don't even mean anything, you often have to suppress them, and then suppress real problems with your code etc.

TL;DR I would really want to see an option to disable the upstream problems 😊

here are some things you can try that may help depending on your use case:

• use the "hint" diagnostic category. this reports a diagnostic rule as a subtle editor hint instead of an error or warning and does not cause the CLI to fail. this may be desirable for diagnostics that you may consider annoying and rarely cause any actual problems, but you still want to be informed of them:
  
• use the baseline feature, which allows you enable stricter diagnostic rules on new code without having to fix all instances of these rules on old code
• depending on what you're doing, it may be best to just disable certain rules entirely. just because every rule is enabled by default doesn't mean we're forcing you to use them. we only do it to ensure that the user is made aware of all possible checks so that they can make an informed decision about disabling a rule, instead of just hiding them all by making them off by default which means 99% of users would never even know about many rules that they may want enabled if they knew about them. more info