I don't think that trying to do this programmatically via some kind of language construct is a good approach. The public API of a library is the one which is documented as such. That's really all there is to it. Documentation is written explicitly by the author of a package and languages provides a lot more nuances than using some programmatic mechanism. E.g. you may have situations where you have more than one level of documented APIs, e.g. a public stable one and an experimental one which is likely to change over time, or a high level one and a low-level one, where more care has to be applied in using it. Or you have APIs which are deprecated but still public and you know that the APIs will go away in a future version, so you should probably not start using them in new code and plan for a refactoring of existing code. Superimposing the extra meaning of __all__ = "public API", which has been done at times, is misleading, esp. when using "from module import *", for which __all__ was added, is frowned upon unless needed in special use cases. You'd really only define __all__ if you expect that "from module import *" will be used, which you typically don't :-) ... "Package authors may also decide not to support it, if they don’t see a use for importing * from their package." https://docs.python.org/3/tutorial/modules.html?highlight=__all__#importing-... Aside: __all__ and namespace package don't work well together either - they don't have __init__.py initializers. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Apr 12 2021)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/