Document adding / creating type hints for CFFI / C / Rust code

[kkirsche]

Documentation

This issue is being created as a request to provide guidance in the official Mypy documentation about the recommended best practices and approaches that users should use when adding type hints to compiled Python code, such as those created in C or Rust and are interacted with via CFFI.

I apologize if this is not the correct place to request this. If this would instead be a better fit for CPython directly (as it may apply to all type checkers rather than just mypy), please let me know where you would like me to file an issue for this, and I'll happily follow up on that for you.

Thanks for your time and all you do.

[hauntsaninja]

Here's a quick overview of what exists:

General overview of writing stubs: https://typing.readthedocs.io/en/latest/source/writing_stubs.html Some notes on packaging stubs with your actual code: https://typing.readthedocs.io/en/latest/source/libraries.html#type-stub-files-included-in-the-package The stubgen docs themselves: https://mypy.readthedocs.io/en/stable/stubgen.html

I think anything that's not stubgen specific could live well at https://typing.readthedocs.io . That documentation is maintained in the https://github.com/python/typing repo

[kkirsche]

Ok, so it sounds like going to the other repo is the way to go. I'm not thinking about stubgen but rather as an author of a library with compiled code or a contributor to a library with compiled code, I've struggled to find any documentation that shows examples of providing type hints as part of that library. That may just be me though, and I greatly appreciate the time to respond and the references.

If it helps for context, I'm trying to build out types for the https://github.com/osohq/oso Python libraries which leverage CFFI to interface between rust and Python. I can type the Python code but am lost with how to type the rust code that is being called via CFFI.

EDIT: add link to repo

[kkirsche]

That's disappointing that this is considered not planned and isn't well documented.

[AlexWaygood]

As Shantanu stated, and as you agreed, any additional documentation on this topic should be contributed to https://github.com/python/typing. As that is a different repo, maintained by a different (albeit overlapping) group of people, there is nothing actionable for the mypy maintainers. As such, it is appropriate for this issue, which is open on the mypy issue tracker, to be closed.

It is "not planned" for mypy to add any additional documentation here. That doesn't close the door on additional documentation being added at the separate https://github.com/python/typing repo. If you want that to happen, you should open an issue (or better yet, a PR) at that repo.

[kkirsche]

Yep. For me it was simply a point about the communication from GitHub in email around issues like this when closed without a comment, not necessarily a criticism of the decision.

If it had been paired with "Closing as discussed in https://github.com/python/mypy/issues/15559#issuecomment-1622615665" would have addressed where that came from.

Fully understood though Alex and I should have articulated this more clearly. Sorry for any confusion or frustration.

EDIT: grammar fixed from typing on mobile