Plugin hook to selectively silence error messages

For developing an Either-like monad that types correctly and also behaves nicely at runtime I currently use the following pattern to independently declare the types for mypy and the runtime implementation

from typing import Generic, TypeVar, TYPE_CHECKING

L = TypeVar('L')
R = TypeVar('R')

if TYPE_CHECKING:  # type declarations

    class Either(Generic[L, R]): pass
    Left = Either[L, None]
    Right = Either[None, R]

else:  # runtime implementation

    class Either(): pass
    class Left(Either): pass
    class Right(Either): pass


# type checking features
a: Left[int] 
b: Either[int, None]

a = b  # typechecks
b = a  # typechecks 

# runtime features
isinstance(Left(), Left)  #works at runtime 
isinstance(Left(), Either)  #works at runtime

During static analysis it is important that Left and Right get treated as aliases for Either so that assignments get typechecked correctly (even though at runtime they are subclasses (and thus subtypes) of Either). Additionally I'd like to be able and use isinstance checks at runtime to determine whether a result is an instance of Left or Right (or more general if something is an instance of Either). This mostly works (assignments typecheck and runtime behavior is as excepted), however mypy (rightfully) complains about the isinstance checks that

Parameterized generics cannot be used with class or instance checks mypy(error)

In cases like these it would be useful if one could tell mypy that a generic class can be used with instance checks. This would also be somewhat similar to how one can declare protocol classes to support runtime instance checks with the @runtime_checkable decorator.

This would also allow user defined generics to behave similar to types from typing like List where

isinstance([1,2,3], List)  # typechecks
isinstance([1,2,3], List[int])  # Parameterized generics cannot be ...

vs

isinstance(Left(1), Left)  # should typecheck, currently doesn't
isinstance(Left(1), Left[int])  # Parameterized generics cannot be ...

I'd propose that @runtime_checkable marks an Generic accordingly so that in the example it would be

#...
if TYPE_CHECKING:  # type declarations

    @runtime_checkable
    class Either(Generic[L, R]): pass

#...

Addendum

The issue is actually not with Either per se but rather with the type aliases Left and Right. For mypy

isinstance(Left(1), Left)  #looks similar to 'isinstance([1,2,3], List)'

actually is

isinstance(Left(1), Either[L, None])  # looks similar to 'isinstance([1,2,3], List[int])'

I still think this would be a useful feature to be able and better support the dynamic nature of Python with the if TYPE_CHECKING pattern.

I am quite sure there was a very similar feature request but can't find it. I think a better idea is to add a plugin hook to selectively suppress some error codes (now that we have them) on a given line. Otherwise it sounds too niche.

Yes, I agree that this is a special case of "there is this error that I know I want to ignore". For this a plugin that gets called at the very end, when everything else is done, would be very useful. Is there already a way to filter out error messages/error codes in the plugin hooks that are already available?

Well, technically I can't say no, because I would be lying, but I really think you should not do this, better wait for the public API. The error manager is exposed though private type checker API ctx.api.msg.errors but trying to do something there is super-fragile.

Even if this were not fragile (at the moment), I wonder to which symbol one would attach such a plugin to, isinstance or Either?

@SaschaSchlemmer get_function_hook() for isinstance(). But this is the last thing I say here :-)

@ilevkivskyi

@ilevkivskyi As discussed in the pull request about ignoring errors by regex, I would like to help you with improving the plugin system, so errors could be ignored from a plugin.

First I need to get more familiar with the plugin system of mypy. I will learn more about it in the next days. However my current idea would be to add a hook, which is called every time when an error should reported. This hook can than decide, if the error should be ignored or not.
For this the hook would need the info object of the error, which holds many useful information to do this decision.

However, this would mean to introduce a new hook and to make the class of the info object public for plugins. When I understand your discussion in this thread correctly, both are think you normally avoid, right? Do you have another approach in mind?

Thanks for your assistance here,
André

Should this have the label topic-pep-604? This seems like it might given other open issues with that label.

Navigation Menu

Repository navigation

Plugin hook to selectively silence error messages #7468

Addendum

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Plugin hook to selectively silence error messages #7468

Description

Addendum

Activity

ilevkivskyi commented on Sep 5, 2019

stereobutter commented on Sep 5, 2019

ilevkivskyi commented on Sep 5, 2019

stereobutter commented on Sep 6, 2019

ilevkivskyi commented on Sep 6, 2019

Netzeband commented on Dec 10, 2019

hunterC90 commented on Feb 22, 2024

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions