You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The standard library's enum.Enum has a class method†__call__ that can take a member of the enumeration, or a member's value, and returns that member in either case.
One possibility, of course, would be for mypy to produce no errors. But this is a somewhat odd situation, so failing that, there should be a way‡ to signal to mypy that this is what's happening.
I couldn't find any such way, short of # type: ignore. Overriding and annotating __call__ didn't work:
This definition type-checks fine, but it doesn't affect the previous errors. (It's worth noting that this doesn't seem to actually override anything; the calls bypass it and go for the metaclass.)
It is possibly to go the other way and adapt the code to suit mypy, by making the use of __call__ explicit. This type-checks fine:
Searching for existing issues or Q&As didn't turn up anything that looked like it matched. There are some issues related to the functional API (e.g. #10469, a dupe of #6037), which also uses __call__, but mypy specifically supports that. There's also #15024, but that appears to be about __call__ on an instance.
Actual Behavior
main.py:10: error: Missing positional argument "radius" in call to "Planet" [call-arg]
main.py:10: error: Argument 1 to "Planet" has incompatible type "Planet"; expected "float" [arg-type]
main.py:13: error: Missing positional argument "radius" in call to "Planet" [call-arg]
main.py:13: error: Argument 1 to "Planet" has incompatible type "tuple[float, float]"; expected "float" [arg-type]
Found 4 errors in 1 file (checked 1 source file)
Your Environment
Mypy version used: 0.982 locally, latest on playground
Mypy command-line flags and config options: none
Python version used: 3.11.6 locally, 3.12 on playground
‡ Preferably something obvious, to be PEP 20-compliant. 😉 ("There should be one—and preferably only one—obvious way to do it. Although that way may not be obvious at first unless you're Dutch." Maybe the problem is that I'm not Dutch?)
The text was updated successfully, but these errors were encountered:
Bug Report
The standard library's
enum.Enum
has a class method†__call__
that can take a member of the enumeration, or a member's value, and returns that member in either case.It is also possible to override the enumeration's
__init__
. The Python docs show an example that uses this to attach additional data to the members.If this is done, mypy reports an error when calling the class, expecting the call to follow the signature of
__init__
.To Reproduce
Playground
This is a stripped-down example of the one from the Python docs. It runs successfully (the asserts pass).
Expected Behavior
One possibility, of course, would be for mypy to produce no errors. But this is a somewhat odd situation, so failing that, there should be a way‡ to signal to mypy that this is what's happening.
I couldn't find any such way, short of
# type: ignore
. Overriding and annotating__call__
didn't work:This definition type-checks fine, but it doesn't affect the previous errors. (It's worth noting that this doesn't seem to actually override anything; the calls bypass it and go for the metaclass.)
It is possibly to go the other way and adapt the code to suit mypy, by making the use of
__call__
explicit. This type-checks fine:But that seems backwards to me.
Searching for existing issues or Q&As didn't turn up anything that looked like it matched. There are some issues related to the functional API (e.g. #10469, a dupe of #6037), which also uses
__call__
, but mypy specifically supports that. There's also #15024, but that appears to be about__call__
on an instance.Actual Behavior
Your Environment
† Technically it's implemented on the metaclass rather than by
@classmethod
.‡ Preferably something obvious, to be PEP 20-compliant. 😉 ("There should be one—and preferably only one—obvious way to do it. Although that way may not be obvious at first unless you're Dutch." Maybe the problem is that I'm not Dutch?)
The text was updated successfully, but these errors were encountered: