Add library stubs for use with mypy

[thofler]

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

[ni-jfitzger]

@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.

[ni-jfitzger]

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.

[marcoskirsch]

Seems like a duplicate of #1887

[ni-jfitzger]

We're in agreement, then. I'll close it.

[ni-jfitzger]

Duplicate of #1887

[bkeryan]

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.