fix: improve type checking

[daniel-sanche]

Fixes #2410

We currently have mypy pinned to an older version, because it fails on newer ones

This PR unpins the dependency to use the latest version, and fixes the problems it finds:

• the *_operation methods in _mixins accept None values, but don't properly handle the None case
• _get_default_mtls_endpoint doesn't handle what happens if the regex check returns None
• the logger interceptor converts bytes to strings, without being explicit about the expected format
• various type annotations didn't match the actual return type

[gemini-code-assist]

Summary of Changes

Hello @daniel-sanche, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses the long-standing issue of mypy being pinned to an older version by resolving several type-checking discrepancies identified by newer mypy versions. The changes involve enhancing type annotations for better accuracy, implementing robust handling for None request objects in mixin methods, and improving the string representation of pickled objects in logging. These updates collectively enable the project to utilize the latest mypy features and maintain stricter type consistency.

Highlights

• Mypy Version Unpinning: The mypy dependency is unpinned, allowing the use of the latest version, which was previously restricted due to compatibility issues.
• Request Object Handling: Methods in _mixins that accept request objects now explicitly handle None values by initializing an empty dictionary, ensuring proper protobuf coercion.
• mTLS Endpoint Robustness: The _get_default_mtls_endpoint function now correctly handles cases where the API endpoint regex match returns None, preventing potential errors.
• Logger Interceptor Clarity: The logger interceptor's conversion of bytes to strings now uses the !r format specifier for a more explicit and readable representation of pickled objects.
• Type Annotation Refinements: Various type annotations across client and mixin templates have been updated to accurately reflect return types and accepted parameter types, including the use of Optional[Union[...]].

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request successfully addresses the issues identified with mypy by unpinning its version and resolving the type-related problems it exposed. The changes include adding type hints for better clarity, handling None values in request objects, and improving logging for debugging. The addition of --check-untyped-defs to the mypy configuration enhances the strictness of type checking, which is a positive step for code quality. Overall, the changes improve the robustness and maintainability of the generated code.

[gemini-code-assist]

This if m is None check is a critical improvement. Without it, accessing m.groups() when mtls_endpoint_re.match(api_endpoint) returns None would lead to an AttributeError. This ensures the function handles cases where the API endpoint does not match the expected regex pattern gracefully.

[gemini-code-assist]

This if m is None check is a critical improvement. Without it, accessing m.groups() when mtls_endpoint_re.match(api_endpoint) returns None would lead to an AttributeError. This ensures the function handles cases where the API endpoint does not match the expected regex pattern gracefully.

[gemini-code-assist]

Initializing request to an empty dictionary when it's None is a good practice. This ensures that the subsequent isinstance(request, dict) check and keyword expansion for protobuf message construction work as expected, preventing potential TypeError or AttributeError if None was passed directly.

[gemini-code-assist]

Initializing request to an empty dictionary when it's None is a good practice. This ensures that the subsequent isinstance(request, dict) check and keyword expansion for protobuf message construction work as expected, preventing potential TypeError or AttributeError if None was passed directly.

[gemini-code-assist]

Initializing request to an empty dictionary when it's None is a good practice. This ensures that the subsequent isinstance(request, dict) check and keyword expansion for protobuf message construction work as expected, preventing potential TypeError or AttributeError if None was passed directly.

[gemini-code-assist]

Initializing request to an empty dictionary when it's None is a good practice. This ensures that the subsequent isinstance(request, dict) check and keyword expansion for protobuf message construction work as expected, preventing potential TypeError or AttributeError if None was passed directly.

[gemini-code-assist]

Initializing request to an empty dictionary when it's None is a good practice. This ensures that the subsequent isinstance(request, dict) check and keyword expansion for protobuf message construction work as expected, preventing potential TypeError or AttributeError if None was passed directly.

[gemini-code-assist]

Initializing request to an empty dictionary when it's None is a good practice. This ensures that the subsequent isinstance(request, dict) check and keyword expansion for protobuf message construction work as expected, preventing potential TypeError or AttributeError if None was passed directly.

[gemini-code-assist]

Adding --check-untyped-defs to the mypy command enforces stricter type checking, which is a good practice for maintaining high code quality and catching potential type-related bugs early. Including *session.posargs also makes the nox session more flexible for custom mypy runs.

[gemini-code-assist]

Adding a test case for custom_endpoint improves the test coverage for _get_default_mtls_endpoint, ensuring it behaves correctly with non-standard API endpoint formats.