Prepare source lookup without moving dataclass value analysis - #6
Merged
Merged
Conversation
This was referenced Oct 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First-use dataclass analysis on Python 3.10–3.12 repeatedly parses and walks the complete source module. Derive bounded module-AST and qualified-class-source views from current source contents, and expose source-only preparation on the existing SignatureAnalyzer owner. Python 3.13+ keeps its native locator.
Preparation does not evaluate annotations/default factories or populate the completed value-analysis cache. Live loader/source/name changes, factory-mutated field/inherited documentation, failure/retry behavior and generated-class fallback remain at their original observation points. OpenHCS registry warmup is the concrete consumer; no consumer-side class roster or per-function optimization is added.
Validation: 136 upstream tests pass (127 existing + 9 source/factory/mutation controls); the actual 44 registered OpenHCS types retain identical fields, annotations, defaults, required flags and documentation. Source controls ran on installed Python 3.12 and 3.14; 3.10/3.11/3.13 locator behavior was verified against official CPython source, not executed in extra environments. Local replay: 413–475 ms cold analysis to about 43 ms after 135 ms source preparation. With the concrete OpenHCS registered-roster readiness consumer, four ordinary uninstrumented Illumination runs in ABBA order measured mean compilation 0.962152 → 0.587605 s and total pipeline time 1.693765 → 1.363694 s (READY/server startup and shutdown excluded). Execution 0.382655 → 0.400589 s shows no execution gain. All four complete authored image inventories passed exact byte parity against the retained qualified native-input reference; native CP was not rerun in this experiment. Consumer commit: OpenHCSDev/openhcs@7258826. Science receipt SHA256: 918c36612ec20738ad2d2760da85c9e9be07e81d4cd4bf0f60ec91dfcf906488. Only two observations per variant; these are representative measurements, not a broad scaling claim. CI passes every 3.11/3.12 platform and all nine added controls on 3.10; three pre-existing recursive projection tests still fail on 3.10, in unchanged code.
Closes #5