Fix type hinting for the Python module #1287
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The type hinting introduced by PR #755 is broken. By inspection of the stub files
*.pyi
it appears that the utility toolstubgen
from themypy
package is producing garbage for modules generated by Cython .This PR replaces the usage of
stubgen
by a new Python scriptpyxstubgen.py
that parsesjsbsim.pyx
to find all the classes, methods and functions declarations with their type hints and then generates a proper stub file_jsbsim.pyi
.Since parsing a Cython file is no trivial job, the script
pystubgen.py
is using the lark parser (a parser toolkit fully written in Python). A grammar filecython.lark
has been created for that purpose. It is the minimum grammar that works for the JSBSim cython code and is by no means pretending to be able to read any cython file.This PR is addressing some proverbial itch scratching: I am annoyed that my favorite IDE does not autocomplete the classes and functions from the JSBSim Python module. I have run some tests that confirm that autocomplete works when the Python module is generated using the new script
pyxstubgen.py
.Please note that this feature is meant to be used by our CI workflow when building the packages that will uploaded to PyPI. It is not part of the standard development cycle (i.e. write code/build/tests) so developers do not need to install
lark
on their systems.