-
Notifications
You must be signed in to change notification settings - Fork 20
Description
Before submitting
- I understand that this project is maintained in spare time and that not all issues may result in changes.
Description
Summary
exstruct/__init__.py currently re-exports multiple public APIs for convenience.
However, this also makes import exstruct relatively heavy, and in the CLI path it contributes to early loading of transitive dependencies through imports such as from exstruct import process_excel.
To reduce package import overhead, we should lighten exstruct/__init__.py and introduce lazy exports for public APIs.
Problem
Heavy imports in __init__.py cause several issues:
import exstructitself becomes slower- the CLI pays broad import cost just to access
process_excel - convenience re-exports negatively impact startup performance
- Python API consumers also pay unnecessary initial import cost
This becomes especially costly when imports eventually pull in dependencies such as pandas, numpy, xlwings, or rendering-related modules.
Proposal
Adopt one of the following approaches, or a combination of them:
Option 1: Wrapper-function exports
Expose public functions such as process_excel via thin wrappers in __init__.py, and import the real implementation inside the wrapper body.
Option 2: PEP 562 lazy exports
Use module-level __getattr__ so symbols are imported only when accessed.
Option 3: Reduce re-export surface
Keep __init__.py minimal and require heavier APIs to be imported from submodules directly.
Expected benefits
- Faster
import exstruct - Lower startup cost for CLI code paths that currently rely on
from exstruct import process_excel - Clearer package boundaries
- Better import-time performance for Python API consumers
Scope
Potential files:
src/exstruct/__init__.py- possibly
src/exstruct/engine.py - possibly related render/core import-path cleanup
Acceptance criteria
import exstructshows measurable improvement in import time- Public API compatibility is preserved as much as possible
- CLI startup cost related to importing
process_excelis reduced - Type-checking and documentation tooling remain usable with acceptable impact
Notes
This change benefits not only the CLI but also Python API users, so it has broader architectural value.
However, because it touches the public package surface, it should be handled a bit more carefully than A/B.
Minimal example (optional)
No response
Additional notes (optional)
No response