Generate additional Type Hints for the Dictionary Form of Messages & Enums
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 30/100
Direzione di ricerca
Inizia tracciando i messaggi dataclass generati e gli entry point esistenti from_dict() e to_dict(); l’issue non indica file o test del repository. Confronta gli esempi richiesti di DocumentTypeStringified e DocumentDict, risolvi i casi limite relativi a bytes e denominazione e verifica che i suggerimenti generati supportino i casi d’uso di conversione dei dizionari e validazione.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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]
- Lingua principale
- Python
- Stelle
- 1.8k
- Fork
- 235
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di danielgtaylor/python-betterproto
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
-
bug investigation needed
Difficoltà 3/5 1-2 giorni Idoneità per principianti 42/100
-
bug investigation needed
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
-
bug investigation needed
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
danielgtaylor/python-betterproto#676 · 3 commenti ·
Tutte le issue di danielgtaylor/python-betterproto
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
CLIMADA-project/climada_python#1337 ·
I maintainer di solito rispondono entro 3 giorni
-
tail without reverseAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
8go/matrix-commander#233 ·
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
-
documentation enhancement priority:high size:M
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Validate non-divisible effective batch sizes in the Unsloth LoRA backendForse già presa @debesh-biswas l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100