[WIP]feat: add signature source

[toaction]

This PR is primarily to prepare for extracting method signatures from Python classes in the future.

In Python-defined classes, there are instance methods and class methods, both of which have special parameters:

def walk(self, name):
    pass

@classmethod
def say(cls, msg):
    pass

Among them, the first parameter of instance methods is self, representing the instance itself. The first parameter of class methods is cls, representing the class itself. Method signatures obtained using inspect.signature also contain cls and self parameters.

walk(self, name)

say(cls, msg)

However, for Python class methods written in C (such as numpy.ndarray.xxx), signatures cannot be obtained through reflection and can only be extracted from documentation. But documentation declarations do not provide cls or self parameters, which differs from Python-defined method signatures.

walk(name)

say(msg)

When generating LLGo Bindings, cls and self parameters should not be used as input parameters for Go methods.

//llgo:link (*Animal).Walk py.Animal.walk
func (*Animal) Walk(name *py.Object) *py.Object {
    return nil
}

//go:linkname AnimalSay py.Animal.say
func AnimalSay(msg *py.Object) *py.Object

To correctly parse method signature information in the future, it is necessary to clarify the source of the signature. If the signature is obtained through reflection, the first parameter needs to be skipped; if the signature is obtained from documentation, no additional processing is required.

[gemini-code-assist]

Summary of Changes

Hello @toaction, 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 introduces a significant improvement to how function signatures are represented and retrieved within the system. By moving from a simple string representation to a more structured Signature object that includes the source of the signature, the change enhances the accuracy and traceability of function metadata. This refactoring ensures that the system can differentiate between signatures obtained from various methods (like Python's inspect module, docstrings, or default paradigms), leading to more robust and informative code generation or analysis.

Highlights

• Enhanced Signature Representation: The system now stores not only the string representation of a function's signature but also its origin (e.g., from Python's inspect module, docstrings, or a default paradigm).
• New Data Structures: Introduced a Signature struct and a SigSource enum in symbol/symbol.go to precisely capture signature details and their source.
• Improved Signature Retrieval: The getSignature function has been refactored to return the new Signature struct along with an error, and includes logic to populate the Source field based on the signature's origin.
• Type Safety and Clarity: Updated the Symbol struct and related code to use the new Signature type, improving type safety and clarity in handling function signatures throughout the codebase.

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 a Signature struct to store not just the signature string but also its source (e.g., from inspect or doc). This is a great enhancement for traceability and debugging. The changes in pydump and pygen are consistent with this new structure. I have a couple of suggestions to improve robustness and the readability of the generated JSON output.

[niupilot]

Code Review Summary

Overall Assessment: Good quality implementation with a well-structured approach to signature source tracking. The change from string signatures to structured objects improves type safety and maintainability.

Key Issues to Address:

• Critical: Missing Go documentation for new public types (SigSource, Signature)
• High: Update design documentation to reflect API changes
• Medium: Add function documentation for signature extraction logic

Performance Impact: Minimal (+8 bytes per Symbol) with good benefits for debugging and future optimization.

Security: No significant vulnerabilities found. Clean implementation with proper error handling.

The structured signature approach is a solid improvement that will make future enhancements easier.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.07%. Comparing base (b25d8f6) to head (0b9d4ac).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #41      +/-   ##
==========================================
+ Coverage   51.62%   52.07%   +0.45%     
==========================================
  Files           6        6              
  Lines         461      457       -4     
==========================================
  Hits          238      238              
+ Misses        194      191       -3     
+ Partials       29       28       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[MeteorsLiu]

As far as i'm concerned, the usage of signature source here, is only to indicate to remove first param of functions which are from PyDoc, because of PyDoc convention.

In conclusion, the only usage of signature source is to make some one know it's from PyDoc, so then they can remove the first param.

Hence, why not handle it here? It seems that exporting signature source is unnecessary.

[luoliwoshang]

Meanwhile, I also have a suggestion: the current architecture extracts all signature strings first, then parses these strings during the pygen phase to obtain structured data before generating code. I think this step should also be moved forward to the pydump stage, so that pygen only receives the processed structured data and can focus solely on Go code generation.