Fill in gaps in type annotations.

[SethMMorton]

This is intended to address issue #234.

It turns out that mypy does not look at the annotations in the main .py file if a stub .pyi file exists. So, functionality added since the .pyi files were created that had annotations in-place were not having those annotations exported, resulting in a small subset of functionality missing type hints for this module.

These gaps have been addressed.

The following related changes have also been made:

• Tests now run mypy.stubtest to verify that the .pyi and .py files are in sync, ensuring this does not happen in the future
• Tests now explicitly run mypy instead of using the pytest-mypy plugin (this plugin was not actually running mypy)
• The annotation for path.Path.joinpath() has been fixed so that it no longer reports its return type as Any

[SethMMorton]

@jaraco Let me know if I have to modify any of my changes to conform to a style guide.

[jaraco]

Thanks @SethMMorton for investigating and working on a solution.

It turns out that mypy does not look at the annotations in the main .py file if a stub .pyi file exists.

My first instinct is that this change takes the project in the wrong direction. Ideally, there should be no need for a stub file and it should be possible to put annotations directly on the code (e.g. #221). The fact that the ecosystem doesn't allow for an incremental transition from a stub file to inline annotations is quite annoying. That seems like a deficiency in mypy and not in this project. In any case, we need to work toward moving all of the annotations out of the stub file and into the source file, and not the reverse.

• Tests now explicitly run mypy instead of using the pytest-mypy plugin (this plugin was not actually running mypy)

This change is problemmatic. This project builds on jaraco/skeleton in order to manage systematic concerns across projects in a shared manner (versus applying bespoke maintenance on each project manually). That approach is intended to rely on pytest-mypy to perform type checks. If mypy checks aren't being invoked, that's a bug in the skeleton or elsewhere upstream.

I do see what you're saying - running tests in verbose mode, I don't see mypy running. Looking at pyproject.toml, I see that mypy is disabled due to jaraco/skeleton#143.

I know a lot of progress has been made in getting mypy working again in a number of skeleton-based projects, so it may be time to revert that disablement. Perhaps I'll work on that today.

• Tests now run mypy.stubtest to verify that the .pyi and .py files are in sync, ensuring this does not happen in the future

Again, this concern is managed at jaraco/skeleton and should avoid diverging from that technique unless there's a very strong reason to do so.

---

Would you be interested instead in working on a PR to migrate the type annotations to source code?

[jaraco]

Note that with #233, mypy checks are once again enabled for this project.

[SethMMorton]

Sure - I prefer annotations in-source as well. I'll update this PR to remove the stub files and move all annotations in-source.

Just to make sure I understand, I should remove all changes to how mypy is invoked because that has been updated upstream?