Closed thofler closed 11 months ago
@thofler @marcoskirsch This seems like a duplicate of #1887 . Based on the link in @thofler 's description, stub generation seems like something primarily created for users of libraries, not owners.
I think we'd prefer to add actual type hints. I don't think these stubs would be very useful. From the documentation:
Stubgen generates draft stubs. The auto-generated stub files often require some manual updates, and most types will default to Any. The stubs will be much more useful if you add more precise type annotations, at least for the most commonly used functionality.
Further explanation for @thofler. We code-generate our APIs based on metadata, with only a few hand-coded functions. It wouldn't make sense for us to have a bunch of manually-edited stubs. Better to just generate the annotations.
Seems like a duplicate of #1887
We're in agreement, then. I'll close it.
Duplicate of #1887
Stub files are a way of adding type hints without changing your actual code. It doesn't matter to users whether you add type hints to your code or you add .pyi
stub files.
You can even generate .pyi
stub files if you want. That's what protoc does, if you opt in via the --mypy_out
and --mypy_grpc_out
options.
That said, I think the main reasons to use stub files (Python 2.x compatibility, package stubs separately from the code they are annotating) don't apply here, so it's better to add type hints to the actual code.
Description of issue
It would be nice to be able to use mypy to check for issues in python applications using nidcpower (https://mypy.readthedocs.io/en/stable/).
Consider providing library stubs to enable this to work.
For applications using mypy to check other modules, need to disable checking nidcpower as described in the mypy docs: [mypy-nidcpower.*] ignore_missing_imports = True