-
Notifications
You must be signed in to change notification settings - Fork 6
Proof-of-concept: Python library for Decimal type #37
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
base: main
Are you sure you want to change the base?
Conversation
This commit updates the project metadata in the `pyproject.toml` file to reflect the correct author, homepage, and bug tracker URLs as requested.
This commit fixes the formatting of the `python/README.md` file to align with the project's prettier configuration.
rambleraptor
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Broadly speaking, this is exactly what I had in mind. Convert AEP types <-> language-specific types.
| @@ -0,0 +1,24 @@ | |||
| # Generated by the gRPC Python protocol compiler plugin. DO NOT EDIT! | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
high-level what is the strategy for these generated files? it seems like we'll check it in, but is there a how-to on how to generate these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a regenerate.sh script that basically just runs buf generate.
|
Overall looks good to me! I'm a little back and forth about the to/from interface (feels like we should be using some more enum-focused serde, but with python's typing this might be best we can get. +1 to using the native data types and translated to / from that, rather than forcing adoption of some separate typing system (e.g. protobuf directly) |
|
I think we should also consider whether we can structure the codegen a bit so that we can code-generate the serde functions in a standard way (e.g. using some yaml metadata file). I know that gapic libraries took the tact of being hand-coded by I don't think that's going to be super maintainable long-term. |
Can you elaborate a bit on how this would work? It seems pretty complicated, would have to handle a mix of built-in types (
With LLMs I think it's actually not such a big deal, but maybe you have different kinds of issues in mind than what I'm thinking of. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe this can be a module (decimal.py)? simple enough that it doesn't need to be a package.
This commit introduces a script to regenerate the Python files from their protobuf definitions. The changes include: - A new `python/regenerate.sh` script that uses `buf generate` to handle code generation. - An updated `buf.gen.yaml` to correctly configure the Python and gRPC plugins using the v2 syntax. - Updated import paths in the Python code to reflect the new generated structure. - Updated `python/README.md` to document the new script.
feat: Add script to regenerate protobuf files
Inspired by a recent convo on our Slack channel, this PR breaks ground on having type libraries for the AEP types.
To keep things simple, this PR just adds support for one language (Python) and one simple type (Decimal). If the overall approach looks good, we can add support for more types and languages.
(Note: this PR was generated by http://jules.google)