Use python 3 style type annotations rather than giving type strings in comments. This will remove future sphinx errors where nitpick mode complains about the use of unused symbols. See comments below.
When doing this change, remove the try: ... except ImportError: ... and the pylint: ignore unused blocks from the typing information.
Add mypy to the test suite so that type annotations are maintained by CI.
--
In direct_model.py type Kernel and type KernelModel are used in practically the same environment (both imported from kernel.py solely for type hinting; both have docstrings in kernel.py), yet one causes a sphinx nitpick warning and the other does not. I would rather turn off the broken sphinx nitpick than remove type hints from the code.
Trying with type annotations rather than type in docstrings to see if sphinx can handle it better. This will break python 2.7 compatibility, which we shouldn't care about anymore since 2.7 is no longer supported. A much better solution than removing the type hints, assuming it works.
The tests have now run, and it seems like the type annotation solution will work. Maybe because the symbol is actually used in the file now, whereas it was unused before (with type hints in the comments the interpreter didn't know the symbols were used).
I'm trying something similar for the Calculator symbol problem in compare.py, but I'll reverse it if it fails the tests.
Are we ready for a complete break from 2.7, preferably to 3.8 so we can use Protocol without installing typing_extensions?
Use python 3 style type annotations rather than giving type strings in comments. This will remove future sphinx errors where nitpick mode complains about the use of unused symbols. See comments below.
When doing this change, remove the
try: ... except ImportError: ...and thepylint: ignore unusedblocks from the typing information.Add mypy to the test suite so that type annotations are maintained by CI.
--
In
direct_model.pytypeKerneland typeKernelModelare used in practically the same environment (both imported fromkernel.pysolely for type hinting; both have docstrings inkernel.py), yet one causes a sphinx nitpick warning and the other does not. I would rather turn off the broken sphinx nitpick than remove type hints from the code.Trying with type annotations rather than type in docstrings to see if sphinx can handle it better. This will break python 2.7 compatibility, which we shouldn't care about anymore since 2.7 is no longer supported. A much better solution than removing the type hints, assuming it works.
The tests have now run, and it seems like the type annotation solution will work. Maybe because the symbol is actually used in the file now, whereas it was unused before (with type hints in the comments the interpreter didn't know the symbols were used).
I'm trying something similar for the
Calculatorsymbol problem incompare.py, but I'll reverse it if it fails the tests.Are we ready for a complete break from 2.7, preferably to 3.8 so we can use Protocol without installing
typing_extensions?Originally posted by @pkienzle in https://github.com/SasView/sasmodels/issues/481#issuecomment-955091102