feat: add kw_only support for dataclass init generation

[guan404ming]

Related Issue

#356

Why

Python's standard dataclasses support kw_only parameter to make fields keyword-only in init. This feature was missing from @c_class decorator.

How

• Add KW_ONLY sentinel class for marking keyword-only fields
• Add kw_only parameter to field() function and @c_class decorator
• Update method_init() to generate proper signature
• Add tests

[gemini-code-assist]

Summary of Changes

Hello @guan404ming, 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 significantly enhances the tvm_ffi.dataclasses module by integrating support for keyword-only arguments in the automatically generated __init__ methods. This feature, inspired by standard Python dataclasses, provides greater control over constructor signatures, improving API clarity and preventing accidental positional argument usage for designated fields. The changes involve modifications to field processing, __init__ signature generation, and the introduction of a new sentinel for marking keyword-only sections.

Highlights

• Keyword-Only Argument Support: Introduced the kw_only parameter to the c_class decorator and the field() function, allowing fields to be designated as keyword-only arguments in the generated __init__ method.
• KW_ONLY Sentinel: Added a KW_ONLY sentinel class and instance, mirroring dataclasses.KW_ONLY, to mark all subsequent fields within a c_class as keyword-only.
• Improved __init__ Generation: Refactored and updated the method_init() function to correctly generate __init__ signatures that respect kw_only settings, handling both class-level and field-level specifications, as well as the KW_ONLY sentinel.
• New Test Cases: Added comprehensive test cases to validate the new kw_only functionality, including class-level settings, field-specific overrides, and the behavior of the KW_ONLY sentinel.

🧠 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 introduces support for keyword-only arguments in the __init__ method generated by @c_class, aligning its functionality more closely with Python's standard library dataclasses. The implementation is robust, including a new kw_only parameter for both the @c_class decorator and the field() function, a KW_ONLY sentinel, refactoring of the __init__ generation logic for better clarity, and comprehensive docstring updates and tests. The changes are well-executed, and I have a couple of minor suggestions to improve code clarity and simplify some of the new logic.

[gemini-code-assist]

The check for the KW_ONLY sentinel can be simplified. The class _KW_ONLY_TYPE is an internal detail, and users are expected to use the KW_ONLY instance, as shown in the documentation. Supporting annotations with the internal class _KW_ONLY_TYPE directly is likely unnecessary and could lead to confusion. A simpler check, isinstance(resolved_type, _KW_ONLY_TYPE), would correctly handle cases where the annotation is the KW_ONLY instance and aligns better with how the standard library dataclasses handles its KW_ONLY sentinel.

Suggested change

	if resolved_type is _KW_ONLY_TYPE or isinstance(resolved_type, _KW_ONLY_TYPE):
	if isinstance(resolved_type, _KW_ONLY_TYPE):

[gemini-code-assist]

The error message for the kw_only type check could be more precise for the user. The MISSING value is an internal sentinel for a non-provided argument and not a value a user can pass. The message could be simplified to state that kw_only must be a boolean, which is the expected type from a user's perspective.

Suggested change

	raise TypeError("`kw_only` must be a bool or MISSING")
	raise TypeError("`kw_only` must be a bool")