-
Let's say I'm writing a pypi package and providing types for it. I would like to ensure that my users catch certain classes of typing errors with pyright, for example, here's my best manual attempt to validate that type hints for GOOD_ARGUMENT = ...
BAD_ARGUMENT = 42 # no ints, please!
def foo():
from apackage import main
main(GOOD_ARGUMENT)
E main(BAD_ARGUMENT) # E: Argument of type "..." cannot be assigned to parameter "first_arg" ...
E main() # E: Argument missing for parameter "first_arg"
def bar():
from apackage import Client
main = Client().main
main(GOOD_ARGUMENT)
E main(BAD_ARGUMENT) # E: Argument of type "..." cannot be assigned to parameter "first_arg" ...
E main() # E: Argument missing for parameter "first_arg" I suppose positive tests are trivial: dump the code into a file somewhere under What about negative tests though? Is there a best practice to follow? Or, perhaps, is there a way to ask
The key here being that some are direct type hints, but others, like |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The common way to write negative typing tests is to use a combination of a The Code sample in pyright playground # pyright: reportUnnecessaryTypeIgnoreComment=true
from typing import assert_type
def func(x: int) -> int:
return x
v1 = func(3)
assert_type(v1, int)
func("bad param") # pyright: ignore[reportArgumentType]
func(1) # pyright: ignore[reportArgumentType] |
Beta Was this translation helpful? Give feedback.
The common way to write negative typing tests is to use a combination of a
# type: ignore
or# pyright: ignore
along with thereportUnnecessaryTypeIgnoreComment
check in pyright. The former will suppress the typing error, and the latter will trigger a diagnostic if the# pyright: ignore
is no longer serving a purpose.The
assert_type
function is also useful for typing tests.Code sample in pyright playground