fix: added missing python stub types for units and prefixes - #106
Conversation
Expanded `_core.pyi` to cover missing stub types for units + prefixes.
|
We are grateful for any help so no worries and thanks for this contribution. I have two comments, but note that I am not an expert on stubs. First, I hope the stub file can be automatically built in the very near future in a GH action. We need to update pyO3 for that. It might not cover all cases but it would automatically use the Rust docstrings and automatically translate the rust units. For now, maintaining a hand-written file is fine though. Second, do you also see linter issues with missing stubs for dunder-methods (add, div, etc.) of With regards to your question - imo |
|
Hi @g-bauer, ah yes I haven't add the dunder-methods for SIObject, didn't realise the existing stub does not cover them! I have updated the branch to add those in. I choose to put them at the end so you can review what is added. As to the GitHub action part, happy to do some digging to see if there is any quick fix in the mean time. Don't think any of my Python people knows the sheer amount of work that needs to take place before we can have anything nice in the Jupyter notebook XD. |
|
Thanks for adding those stubs as well! Looks good to me. PyO3 has an experimental feature that allows introspection and generation of stub files. Since this is experimental, features are added across PyO3 versions and in the latest version doc-strings are exported as well. I am not sure whether maturin supports stub-generation already. So it looks like very soon we will get stubs for PyO3 projects for free. But for now - thanks again for the contribution! |
Expanded
_core.pyito cover missing stub types for units + prefixes.Sorry for bothering you guys again, but this one is driving my linter a little nuts so thought it is probably worth raising XD.
Worth noting that on line 177 of the Python stub I am debating between typing the method as:
or
I ended up going with the latter cause it matches the signiture in extra_units.rs::97. However, your current implementation of the method there would suggest the former as the more accurate type signiture. I supposed the flexibility is intentional?