Modernization of typehints in llmcompressor/core/lifecycle.py

[siddhaka]

This PR refactors llmcompressor/core/lifecycle.py for improved readability, consistency, and adherence to modern Python style conventions.

[github-actions]

👋 Hi! Thank you for contributing to llm-compressor. Please add the ready label when the PR is ready for review.

Note: This is required to complete the testing suite, please only add the label once the PR is code complete and local testing has been performed.

[gemini-code-assist]

Summary of Changes

Hello @siddhaka, 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 focuses on modernizing the type hints within the llmcompressor/core/lifecycle.py file. By adopting native generic types and the union operator for optional types, the changes enhance code readability, consistency, and maintainability, bringing the codebase in line with contemporary Python best practices.

Highlights

• Modernized Type Hints: Updated type hints throughout llmcompressor/core/lifecycle.py to use native generic types (e.g., list instead of typing.List) and the union operator (|) for optional types (e.g., Type | None instead of typing.Optional[Type]), aligning with PEP 585 and PEP 604.
• Refined Imports: Removed List and Optional imports from the typing module as they are no longer necessary with the adoption of modern type hinting syntax.
• Code Readability: Improved the formatting of a multi-line assert statement for better readability and adherence to modern Python style conventions.

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 PR does a good job of modernizing the type hints in llmcompressor/core/lifecycle.py by using the | operator for optional types and built-in collection types like list. The changes improve readability and align with modern Python conventions. I have one suggestion regarding a docstring that could be made more accurate.

[rahul-tuli]

Hi @siddhaka, thank you for your contribution, it seems like both #1933 and #1934 changed alot more files than scoped in the PR description, I'm guessing it's due to styling changes, However we would like to keep the PRs crisp, could you rebase the diff on latest main, and limit the changes to intended files, for example if you wanted to change llmcompressor/core/lifecycle please limit the changes to just that file. Kindly let us know if we can help in any way, the diff looks good otherwise

[siddhaka]

I’ve now cleaned up both PRs to include only the intended updates. Please let me know if any further changes are required.

[rahul-tuli]

LGTM! thanks for the contribution

[kylesayrs]

Thanks for the contribution! I have one small nit that I think this worth discussing

From https://docs.python.org/3/library/typing.html#typing.Optional:

On the other hand, if an explicit value of None is allowed, the use of Optional is appropriate, whether the argument is optional or not. For example:

I understand that functionally, Optional and X | None are equivalent, but this comment in the docs (and my personal intuition on the word) suggest that Optional should refer to when the argument is not required to be provided, whereas X | None refers to when the argument must be provided, but could be None.

[rahul-tuli]

Thanks for the contribution! I have one small nit that I think this worth discussing

From https://docs.python.org/3/library/typing.html#typing.Optional:

On the other hand, if an explicit value of None is allowed, the use of Optional is appropriate, whether the argument is optional or not. For example:

I understand that functionally, Optional and X | None are equivalent, but this comment in the docs (and my personal intuition on the word) suggest that Optional should refer to when the argument is not required to be provided, whereas X | None refers to when the argument must be provided, but could be None.

@kylesayrs would you be kind enough to update #1927 to make this more explicit

[rahul-tuli]

A good nit found by @kylesayrs that we'd like to adopt

[kylesayrs]

Looks good! Either Optional or X | None is fine.