PePsY is organized into two user-facing layers.
The stable core is intended for normal application code:
pepsy.boundarypepsy.backendspepsy.fittingpepsy.operatorspepsy.samplingpepsy.solverspepsy.tensors
Stable APIs follow semantic versioning, include regression tests, and receive deprecation warnings before removal whenever practical.
pepsy.interop and the high-level pepsy.optimizers namespace are stable
orchestration surfaces. Their advanced subdomains—such as QMERA, tree and
stabilizer tensor networks, noisy trajectories, and Symmray workflows—remain
explicit domain APIs and may require optional dependencies.
The top-level pepsy namespace is a frozen compatibility facade. Existing
root-level names remain available through lazy aliases, but new public names
should be added to their responsibility-based namespace instead of expanding
pepsy.__init__. Advanced functionality belongs in its explicit domain module
or under pepsy.experimental.
Any proposed root-level addition requires an API-stability review and a regression test. This policy prevents the root namespace from becoming a second, eager import surface while preserving existing user code.
BP, MERA, stabilizer tensor networks, tree tensor networks, Symmray-specific
workflows, and VMC integrations are advanced domains. They are available from
their explicit modules and through pepsy.experimental:
from pepsy.experimental import bp, symmetry, vmc
from pepsy.vmc.torch import TorchVMCDriverThese domains may evolve faster and can have additional dependency or backend requirements. Their public entry points are documented, but implementation details are not compatibility guarantees.
Old flat module paths such as pepsy.core and pepsy.optimize_mps were
removed in the 0.4 package-layout cleanup. Use the responsibility-based paths,
for example pepsy.tensors and pepsy.optimizers.mps.