-
Notifications
You must be signed in to change notification settings - Fork 23
feat: produce and transport resolved symbol tables from Python #332
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -269,6 +269,45 @@ impl PySerializedSymbolTable { | |
| } | ||
| } | ||
|
|
||
| /// Build a ``SerializedSymbolTable`` from its JSON transport | ||
| /// text, as produced by ``to_json_str``. | ||
| /// | ||
| /// This is the inverse of ``to_json_str`` and exists for callers | ||
| /// that carry the transport form across a process or service | ||
| /// boundary — a scheduler persisting the table produced by | ||
| /// ``create_job`` and later handing it to a worker, for instance. | ||
| /// Prefer ``from_symtab`` when the source is an in-memory | ||
| /// ``SymbolTable``. | ||
| /// | ||
| /// Raises ``ValueError`` if the text is not valid JSON. Note that | ||
| /// the *contents* are validated lazily: a well-formed JSON | ||
| /// document whose entries are not valid symbol table entries is | ||
| /// accepted here and rejected by ``to_symtab``. | ||
| #[classmethod] | ||
| fn from_json_str(_cls: &Bound<'_, pyo3::types::PyType>, json: &str) -> PyResult<Self> { | ||
| let inner = openjd_expr::SerializedSymbolTable::from_json_str(json).map_err(|e| { | ||
| pyo3::exceptions::PyValueError::new_err(format!( | ||
| "Failed to parse SerializedSymbolTable JSON: {e}" | ||
| )) | ||
| })?; | ||
| Ok(Self { inner }) | ||
| } | ||
|
|
||
| /// Serialize to the JSON transport text: an array of | ||
| /// ``{"name", "type", "value"}`` objects in canonical | ||
| /// (lexicographic) path order. | ||
| /// | ||
| /// Use this to move a table across a process or service boundary; | ||
| /// pair it with ``from_json_str`` to reconstruct. The result is | ||
| /// stable for a given table, so it is safe to store or compare. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The two guarantees documented here — an array of name/type/value objects "in canonical (lexicographic) path order", and "stable for a given table, so it is safe to store or compare" — only hold for instances built via
Since the docstring actively invites callers to store and compare the text, consider scoping the claim (e.g. canonical order and byte-stability hold for tables built via |
||
| fn to_json_str(&self) -> PyResult<String> { | ||
| serde_json::to_string(&self.inner).map_err(|e| { | ||
| pyo3::exceptions::PyValueError::new_err(format!( | ||
| "Failed to serialize SerializedSymbolTable: {e}" | ||
| )) | ||
| }) | ||
| } | ||
|
|
||
| /// Deserialize this serialized symbol table into a full | ||
| /// ``SymbolTable`` suitable for inspection or modification. | ||
| /// ``path_format`` controls how PATH-typed values are | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Design note on the lazy-validation choice: for the use case the docstring names — a scheduler persisting the transport text and later handing it to a worker — deferring content validation to
to_symtabpushes the error to the worst possible place. The scheduler happily accepts and stores a bad payload, and the failure surfaces later on the worker, far from the input that caused it.Validating structure at ingest (i.e. parsing into the real entry type rather than a loose JSON document) would make
from_json_stra real trust boundary and give the error at the point where the caller still has the offending text in hand. If the laziness is deliberate — e.g.openjd_expr::SerializedSymbolTable::from_json_strintentionally keeps the raw document so unknown future entry kinds pass through untouched — it would help to say so in the docstring, since as written it reads as an accident rather than forward-compatibility.