Decide on preferred set of `mypy` rules to adopt about plasmapy HOT 5 OPEN

I forget the error this raises, but:

def fcn(x:None| int = None):
    if x is None:
         x = 0

    y = x + 1

This raises a mypy error because it thinks x can still be None on the last line, and it drives me crazy since this is a pretty common design pattern!

from plasmapy.

Huh, the mypy error I get from that is no-untyped-def since there's no return type annotation. mypy is usually good at type narrowing, assuming it can infer what's in the if statement. I'm curious if the error you ran into is happening because there's some dynamical typing happening. 🤔 @pheuer — could you ping me the next time you run into an error like this?

I'm wondering if it may be associated with untyped decorators (like @validate_quantities). Otherwise it's sometimes possible to define a TypeGuard.

Thank you for bringing this up!

from plasmapy.

Ah, maybe it is related to decorators? I'll keep an eye out for next time. Here's another pytest specific one

def test_fcn(ex : Exception | None):
    with pytest.raises(ex):
            ...

For some reason mypy is looking for an overloaded function (raising call-overload) for pytest.raises that has Exception as its class, except isn't that just the default (and only?) signature for that function?

from plasmapy.

Interesting! I believe the pytest API changed recently so that pytest.raises no longer accepts None, but we get the call-overload error even after removing the | None. (The source file of pytest.raises contains a few signatures of pytest.raises that are decorated with @overload.) In any case, this is a good motivation to ignore call-overload in all test files since the advantages of having the more in-depth type hints don't outweigh the extra complicatedness of having to do all that. Thanks!

from plasmapy.

When trying to add particlewise to particle_collections.is_category, the static type check for mypy kept raising issues with this code:

The "issue" is that the individual Particle class has a method without particlewise as a keyword, so it would only return a bool, which is not iterable. The third condition can only be called, however, given that it passes the check for isinstance(particle, ParticleList), so this cannot be an issue (unless you can somehow pass that second check otherwise?).

This was frustrating trying to debug. The only way I could think was to use nested conditionals, which then ruff complains about. The solution I used was just to tell mypy to ignore it # type: ignore[arg-type].

I don't know if there's any more clever way.

from plasmapy.