You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I frequently use the dictionary form of betterproto messages (from_dict(), to_dict()) with stringified enums as arguments for web endpoints and database ODMs. Having an exact type hint for the dictionary form would allow for automatic data validation and more.
What is the feature request for?
The core library
The Problem
I frequently use the dictionary form of betterproto messages (from_dict(), to_dict()) as arguments for web endpoints (Quart, Quart Schema) and database ODMs (such as Beanie for MongoDB).
These frameworks often use pydantic for their validation mechanism, as well as documentation generation (such as Swagger). Having an exact type hint for the dictionary form would allow for automatic data validation and more.
Using the original Message type hints directly (i.e. using the @dataclass annotated message classes) is an option. Yet in some of my cases I need to use the stringified form of the protobuf enums, rather than the integer based one. Generating a dynamic type hint in runtime is cumbersome and not a solution.
The Ideal Solution
It would be great to have the dictionary types of messages to be generated side by side with the current dataclasses:
They dictionary types could be later used inside validation frameworks.
Of course, there might be some corner-cases, e.g. what to do in case of bytes? Should this be done by manually extending the DocumentDict class and override it? How should dataclass names be extended without interfering with other messages? Maybe put them into their own python file?
All in all it seems to be a most valuable and maybe even an easy to develop solution for many good use cases.
What do you think?
Best regards
Markus
The Current Solution
Generating a dynamic type hint from proto enums in runtime is cumbersome and not very maintainable.
Summary
I frequently use the dictionary form of betterproto messages (
from_dict()
,to_dict()
) with stringified enums as arguments for web endpoints and database ODMs. Having an exact type hint for the dictionary form would allow for automatic data validation and more.What is the feature request for?
The core library
The Problem
I frequently use the dictionary form of betterproto messages (
from_dict()
,to_dict()
) as arguments for web endpoints (Quart, Quart Schema) and database ODMs (such as Beanie for MongoDB).These frameworks often use pydantic for their validation mechanism, as well as documentation generation (such as Swagger). Having an exact type hint for the dictionary form would allow for automatic data validation and more.
Using the original Message type hints directly (i.e. using the
@dataclass
annotated message classes) is an option. Yet in some of my cases I need to use the stringified form of the protobuf enums, rather than the integer based one. Generating a dynamic type hint in runtime is cumbersome and not a solution.The Ideal Solution
It would be great to have the dictionary types of messages to be generated side by side with the current dataclasses:
They dictionary types could be later used inside validation frameworks.
See the following example:
This would generate to
Now we could use this inside Quart-Schema for parameter validation and documentation:
Of course, there might be some corner-cases, e.g. what to do in case of bytes? Should this be done by manually extending the DocumentDict class and override it? How should dataclass names be extended without interfering with other messages? Maybe put them into their own python file?
All in all it seems to be a most valuable and maybe even an easy to develop solution for many good use cases.
What do you think?
Best regards
Markus
The Current Solution
Generating a dynamic type hint from proto enums in runtime is cumbersome and not very maintainable.
The text was updated successfully, but these errors were encountered: