Text-to-CAD: parametric source, geometry evidence and responsible handoff
Read cadgen’s lazy build123d proxy: import timing, identity and an eager dir call
Inspect the public entry point and test the exact lazy proxy with a fake dependency, without claiming a CAD-kernel benchmark.
What you will learn
- The public namespace defers some work, not all work
- The proxy returns real objects and then caches them
- Test precisely the behavior under discussion
Before you start
- Basic Python functions, modules and file paths
- Understanding of units and the difference between a design and a physical part
Plan a bounded CAD exercise and distinguish source freshness, document inspection, visual review and manufacturing decisions.
Key takeaways
- The proxy caches the actual dependency object, not a wrapper.
- dir and direct object imports can force resolution.
- Isolated proxy tests are not geometry or performance tests.
The public namespace defers some work, not all work
cadgen.__init__ uses module-level attribute lookup to expose format namespaces, assembly helpers, scene utilities and the build123d proxy. Format names return their modules so import and decorator access can retain one identity. This is an API organization decision, not evidence that every imported dependency is cheap.
The package entry point also invokes kernel-import tracking and a font guard at import time. We inspected those calls but did not run the package initializer or audit those helpers in this fixture. Lazy access to geometry classes should not be described as a completely side-effect-free package import.
The proxy returns real objects and then caches them
In cadgen/build123d.py, _REAL starts empty. The first normal attribute request imports build123d, retrieves the real object and stores it in the proxy module’s globals. Later access to that name becomes an ordinary attribute lookup. It does not wrap Box in a new compatibility class.
Missing double-underscore probes raise AttributeError without forcing the heavy import. However, __dir__ asks the real module for its names, so dir(proxy) can force import. Likewise, importing Box directly must resolve the object immediately; attribute-style access preserves laziness until the attribute is actually needed.
Test precisely the behavior under discussion
Eight isolated fixture cases executed the inspected proxy source against a fake build123d module: deferred load, dunder probe, object identity, global cache, repeated and second attributes, dir, direct from-import and unknown attribute failure. The fixture restores module state and never imports a geometry kernel.
These results verify the small proxy mechanism under controlled inputs, not end-to-end CAD generation, real import latency or daemon performance. The source contains a timing claim, but this series does not repeat it as our own measurement. Missing attributes remain errors rather than being silently fabricated.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Trace package entry work separately from lazy attributes.
- 2
Follow first access and the global cache assignment.
- 3
Test introspection as well as ordinary access.
- 4
Report the fake dependency and untested runtime explicitly.
Copy-ready example
{
"fixture": true,
"dependency": "fake build123d module",
"casesPassed": 8,
"cadKernelExecuted": false,
"geometryGenerated": false,
"importTimingMeasured": false
}Frequently asked questions
Is bd.Box a separate wrapper class?
The inspected proxy returns the dependency’s actual object and caches it.
Can merely calling dir trigger the real import?
Yes. The proxy’s __dir__ resolves the real module to collect its names.
Sources
- Text-to-CAD / packages/cadgen/src/cadgen/__init__.pySource checked 2026-09-14
- Text-to-CAD / packages/cadgen/src/cadgen/build123d.pySource checked 2026-09-14