Skip to content

Package import optimization: lighten exstruct.__init__ and introduce lazy exports #109

@harumiWeb

Description

@harumiWeb

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 exstruct itself 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 exstruct shows measurable improvement in import time
  • Public API compatibility is preserved as much as possible
  • CLI startup cost related to importing process_excel is 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

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions