- Author(s): Sourabh Singh
- Approver: gnossen
- Status: Draft
- Implemented in: Python
- Last updated: 2024/08/24
- Discussion at: discussion thread
This proposal aims to add type annotations to the remaining untyped parts of the gRPC Python API. This would allow developers to use static type analysis tools like MyPy to catch potential errors early in the development process.
Type Hints was introduced for a while now, we already added type annotation to python Async APIs since it has a high enough version floor. Now it's time to do the same for Sync APIs.
This proposal plans to add type annotation to python Sync public APIs which allows users to build safer code by running static type analysis tools.
- Loosely related to Async API proposal.
- The proposal includes the part to introduce typing to gRPC Python Async APIs.
We propose to add type annotations to the following:
- All public Python APIs listed in the
__all__
variable : This includes all the core gRPC functionality exposed in thegrpcio.grpc
module.- Example: The
UnaryUnaryMultiCallable.__call__
method would look like this with type annotations:
@abc.abstractmethod def __call__(self, request: RequestType, timeout: Optional[float] = None, metadata: Optional[MetadataType] = None, credentials: Optional[CallCredentials] = None, wait_for_ready: Optional[bool] = None, compression: Optional[Compression] = None) -> ResponseType:
- Implementation: python sync api updates
- Example: The
- gRPC Python Async Code:
- Implementation: python async api updates
- Python ancillary packages: This includes packages like
grpcio-admin
,grpcio-channelz
, etc., which provide additional functionality for gRPC.- Implementation: ancillary packages updates
Adding type annotations to the gRPC Python Sync API would provide several benefits:
- Improved Developer Productivity: Type annotations would help developers catch errors early in the development process, reducing the time spent on debugging.
- Enhanced Code Maintainability: Type annotations would ensure type consistency across the codebase, making it easier to maintain and update the code.
- Enabled Static Analysis: Type annotations would allow static analysis tools like MyPy to effectively analyze gRPC code, leading to earlier detection of potential issues.
After add type annotation, instead of original un-typed API (UnaryUnaryMultiCallable.__call__
):
@abc.abstractmethod
def __call__(self,
request,
timeout=None,
metadata=None,
credentials=None,
wait_for_ready=None,
compression=None):
We'll have typed API which will looks like this:
@abc.abstractmethod
def __call__(self,
request: RequestType,
timeout: Optional[float] = None,
metadata: Optional[MetadataType] = None,
credentials: Optional[CallCredentials] = None,
wait_for_ready: Optional[bool] = None,
compression: Optional[Compression] = None) -> ResponseType:
We propose a phased approach to implementing this proposal:
- Add typing to internal APIs: This would involve adding type annotations to the internal functions and classes used by the gRPC Python Sync API.
- Implementation: PR1: Add typing for some internal python files.
- Add typing to public API and mark it as experimental for at least one release: This would involve adding type annotations to the public API and marking it as experimental to allow for feedback and potential adjustments.
- Implementation: python sync api updates
- Release typed public APIs: Once the experimental phase is complete and any necessary adjustments are made, the typed public APIs would be released as stable.
- Integrate MyPy and typeguard into CI: To ensure type consistency and catch potential errors early, we will integrate MyPy (for static type checking) and typeguard (for runtime type checking) into our continuous integration pipeline.
N/A
This proposal presents a comprehensive approach to providing type hints for gRPC Python applications. By addressing the challenges of type inference, code maintainability, and static analysis, we aim to significantly enhance the developer experience and improve the overall quality of gRPC Python code.