Package transformation frontends for Python v0.4.0 - #9
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 051e12f763
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return bind_transformation_plan( | ||
| plan, | ||
| schema, | ||
| ) |
There was a problem hiding this comment.
Preserve operation spans in SPSS binding results
When callers compile SPSS syntax and inspect compilation.bound.operation_spans, this return now replaces the previous SPSS bound result with the generic two-field BoundTransformation, causing an AttributeError and discarding the spans collected above. Preserve the tuple in a frontend-specific result (or expose it on SpssFrontendCompilation) so the existing source-to-operation mapping remains available.
Useful? React with 👍 / 👎.
What changed
openstatspec.frontends.spssapply_transformation_plan_in_placeAPI for typed plans and strict mappingscompile_spss_syntax,apply_spss_in_place, legacy transform imports, andapply-spsscompatibleapply-planandinstall-in-place-schemaCLI commandsWhy
The previous implementation had a generic canonical plan but placed SPSS-specific parser/compiler files under the generic transform namespace, and the SQL executor compiled SPSS text itself. This made future frontends difficult to add safely.
The new boundary is source syntax → frontend → canonical plan → generic in-place executor.
Invariants
Validation
git diff --check: passed (line-ending notices only)