Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add and Expose Type Hints #98

Open
chasleslr opened this issue Nov 28, 2024 · 3 comments
Open

Add and Expose Type Hints #98

chasleslr opened this issue Nov 28, 2024 · 3 comments
Labels
enhancement New feature or request for-next-release Item included for next release

Comments

@chasleslr
Copy link

chasleslr commented Nov 28, 2024

Summary

Add type hints to the codebase. This includes adding a py.typed file (as per PEP 561) to enable type checkers to use aisuite's type information effectively.

Why is this needed?

  • Improves code readability and maintainability by explicitly defining function signatures and variable types.
  • Enables mypy, pyright, and other type checkers to utilize aisuite's type information when users check their code.
  • Provides completion suggestions for users of pylance or pyright.

Proposed Solution

  1. Add Type Hints:

    • Review all functions, methods, and variables in the codebase and annotate them with appropriate type hints.
  2. Add py.typed File:

    • Include a py.typed file in the package to mark it as PEP 561-compatible.
  3. Integrate mypy:

    • Add mypy as a development dependency in the project.
    • Configure a mypy.ini file or equivalent to define type-checking rules.
    • Ensure mypy checks are part of the CI pipeline.

Additional Context

@OutstandingWork
Copy link

@chasleslr I would like to work on it.

@ksolo ksolo added the enhancement New feature or request label Nov 30, 2024
@rohitprasad15 rohitprasad15 added the for-next-release Item included for next release label Dec 7, 2024
@rohitprasad15
Copy link
Collaborator

Thanks for the suggestion. We will investigate and see if it can be included in next release.

@zby
Copy link

zby commented Dec 9, 2024

This is not an easy task - you need to unify all the types returned by the different providers. For example what should be the return type of 'client.chat.completions.create' call and in particular of the choices[0].message field of that object?

But it would be very very useful if we got these unified types - without that you never know what fields to expect and even if it is an object or just a dictionary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request for-next-release Item included for next release
Projects
None yet
Development

No branches or pull requests

5 participants