This Pull Request provides support for the eventual goal of running mypy as part of Continuous Integration, as noted in #38.
The 2nd patch describes the addition of a py.typed file, which turns INDXParse into being considered a typed project. If this 2nd patch were applied directly to the master branch from when this PR was initially drafted (768430b), some type errors would arise when running this command:
mypy indxparse
The 1st patch fixes those errors preemptively.
The 3rd patch expands mypy review to the package's source tree (i.e. ${top_srcdir}/indxparse), rather than focusing on the initial two scripts @sldouglas-nist and I were reviewing. I believe this does not meet #38's goal of full type checking of the project, as mypy --strict still raises around 1,600 errors. (At a glance, a good chunk of these look like they would be fixed dozens at a time per line of fixed code, so this does not necessarily imply over 1,000 fixes are needed.) While not sufficient, I do think it's necessary: enabling type review over the source tree now should prevent type-based regressions going forward.
Meanwhile, adding py.typed (coming back to patch 2) provides a benefit to downstream consumers of INDXParse that use it as an imported package. I'm drafting a functionality extension that will need to live in its own repository for at least a little while. That repository reviews with mypy --strict, and stumbled into the need for py.typed when it took its first peek into the indxparse.MFT module. For the benefit of any other projects that (1) import INDXParse as a package, and (2) type-review their code, adding py.typed potentially kickstarts a review dialogue that will help prioritize attention on the current typing errors.
Disclaimer:
Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose.
This Pull Request provides support for the eventual goal of running
mypyas part of Continuous Integration, as noted in #38.The 2nd patch describes the addition of a
py.typedfile, which turns INDXParse into being considered a typed project. If this 2nd patch were applied directly to themasterbranch from when this PR was initially drafted (768430b), some type errors would arise when running this command:The 1st patch fixes those errors preemptively.
The 3rd patch expands
mypyreview to the package's source tree (i.e.${top_srcdir}/indxparse), rather than focusing on the initial two scripts @sldouglas-nist and I were reviewing. I believe this does not meet #38's goal of full type checking of the project, asmypy --strictstill raises around 1,600 errors. (At a glance, a good chunk of these look like they would be fixed dozens at a time per line of fixed code, so this does not necessarily imply over 1,000 fixes are needed.) While not sufficient, I do think it's necessary: enabling type review over the source tree now should prevent type-based regressions going forward.Meanwhile, adding
py.typed(coming back to patch 2) provides a benefit to downstream consumers of INDXParse that use it as an imported package. I'm drafting a functionality extension that will need to live in its own repository for at least a little while. That repository reviews withmypy --strict, and stumbled into the need forpy.typedwhen it took its first peek into theindxparse.MFTmodule. For the benefit of any other projects that (1) import INDXParse as a package, and (2) type-review their code, addingpy.typedpotentially kickstarts a review dialogue that will help prioritize attention on the current typing errors.References:
Disclaimer: Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose.