Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Generate additional Type Hints for the Dictionary Form of Messages & Enums

未关闭
  • 哪里不对？
#584 1 条评论 3 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
30/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
停滞
技术栈
python
领域
tooling

调研方向

首先跟踪生成的 dataclass 消息以及现有的 from_dict() 和 to_dict() 入口点；该 issue 没有指明任何仓库文件或测试。比较所请求的 DocumentTypeStringified 和 DocumentDict 示例，解决 bytes 和命名方面的边界情况，并验证生成的类型提示是否支持字典转换和验证用例。

由索引模型根据 Issue 内容生成。

描述

enhancement
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:

enum DocumentType {
  UNKNOWN = 0;
  CONTRACT = 1;
  INVOICE = 2;
}

message Document {
  DocumentType type = 1;
  string content = 2;
}

This would generate to


# Currently generated
class DocumentType(betterproto.Enum):
    UNKNOWN = 0
    CONTRACT = 1
    INVOICE = 2

@dataclass(eq=False, repr=False)
class Document(betterproto.Message):
    type: "DocumentType" = betterproto.enum_field(1)
    content: str = betterproto.string_field(2, group="_data")

# Additionally generated
class DocumentTypeStringified(str, Enum):
    UNKNOWN = "UNKNOWN"
    CONTRACT = "CONTRACT"
    INVOICE = "INVOICE"

class DocumentDict(TypedDict):
    type: DocumentTypeStringified
    content: str

Now we could use this inside Quart-Schema for parameter validation and documentation:

app = Quart(__name__)
QuartSchema(app)


@app.post(
    "/documents/<document_name>",
)
@validate_request(
    DocumentDict,
)
async def create_document(document_name: str, data: DocumentDict):
    document = Document().from_dict(data)
    await db.save_document(document)
    return jsonify(success=True), 200

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.

DocumentTypeEnumStringified= Enum("DocumentTypeEnumStringified", [item.name for item in DocumentTypeEnum])

class MyDbDocument(Document):
    type: Annotated[str, DocumentTypeEnumStringified]
主要语言
Python
星标
1.8k
派生
235
30 天内没有已合并 PR

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

danielgtaylor/python-betterproto 的其他 Issue

查看 danielgtaylor/python-betterproto 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。