Python libraries often need to maintain a stable public API even as internal implementations evolve, gain new backends, or depend on heavy optional libraries. In Python, where internal objects are easy to inspect and import, users can come to rely on "reachable internals" that were never intended to be public, making refactoring risky and slowing long-term maintenance. This paper revisits the pointer-to-implementation (PIMPL) idiom from C++ and reinterprets it as a Pythonic pattern of opaque delegation: a small public object (or module) that delegates its behavior to a separate implementation object treated as internal. We situate this pattern within a broader taxonomy of encapsulation techniques in Python, relate it to existing practices such as module-level indirection, facade objects, and backend dispatch, and identify PIMPL-like structures already used in the standard library and the scientific Python ecosystem. We then show how a Pythonic PIMPL can be used in existing codebases to isolate heavy dependencies, support lazy imports, and enable runtime selection of alternative backends without changing the public API. Finally, we discuss the benefits and trade-offs of the approach and offer practical guidance on when the pattern is appropriate and how to apply it in large, long-lived Python libraries.

翻译：Python库通常需要在内部实现演进、新增后端支持或依赖重型可选库时，仍保持稳定的公共API。在Python中，由于内部对象易于检查和导入，用户可能依赖那些本不应公开的"可访问内部实现"，这使得重构存在风险并拖慢长期维护进程。本文重新审视C++中的指针到实现（PIMPL）惯用法，将其重新诠释为一种Pythonic的不透明委托模式：即通过小型公共对象（或模块）将其行为委托给被视为内部实现的独立对象。我们将该模式置于更广泛的Python封装技术分类体系中，关联到模块级间接调用、门面对象和后端调度等现有实践，并识别标准库及科学Python生态中已使用的类PIMPL结构。随后展示如何将Pythonic PIMPL应用于现有代码库，以隔离重型依赖、支持延迟导入，并在不改变公共API的前提下实现运行时替代后端的选择。最后，我们讨论该方法的优势与权衡，并就该模式的适用场景及其在大型长期维护Python库中的实施提供实践指导。