mirror of
https://github.com/zap-proto/py.git
synced 2026-10-30 15:04:09 +00:00
zeekay
b51be46fa8
The whitespace-significant .zap schema is the estate's default form, but
Python could not read one at all — bindings had to be written by hand, which
is how two runtimes start disagreeing about what a schema means.
zap.schema reads it the same two steps as zap-proto/go's cmd/zapgen: desugar
rewrites the whitespace form into the canonical brace form (a near-identity
that only ADDS the {}/@offset tokens the brace grammar requires, so a brace
file round-trips byte-for-byte), then one parser handles both styles. Field
offsets come from the same slot widths, so both runtimes lay a schema out
identically.
emit renders one module per schema: zero-copy views over zap.wire (wrap
parses, properties read fields in place at their schema offsets, build
writes) and, per interface, an ordinal enum, a handler Protocol, a dispatch
function and a typed client. Channel and CallFailed move into zap.pipeline,
where the RPC model already lives, so a generated module declares only the
schema's own names.
Pinned against Go two ways: the desugar cases are cmd/zapgen/desugar_test.go
verbatim, and the generated Ping.build / BaseTx.build must reproduce the
bytes Go's own generated bindings write. Across the 263 unique .zap files in
the estate the two generators agree on accept-or-reject for every one.