Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#584 コメント 1 件 リアクション 3 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

danielgtaylor/python-betterproto のほかの issue

danielgtaylor/python-betterproto の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。