Sorry for the omnibus reply. The PEP has come a log way! My major concerns are at the bottom. First some nits.
I feel that the previous discussion thread should be linked from this thread for future reference, so here it is: PEP 842: Module Exports.
A future import is supposed to be a temporary measure; at some point the future behavior will be the default, otherwise a future import is not appropriate (despite an existing a counterexample). However, we could use some other explicit marker if we feel a marker is necessary. (Random idea: we could require setting __export__ = [] before export is used.)
I fundamentally disagree ith Paul (and some others) that it is a “long-established principle” that everything in a module is public. That was simply the default behavior, stemming from the original implementation – when you have no way to express what’s public and what isn’t, the only sensible default is to make everything public. There is no “God-given right” to be able to open up a module at runtime. (You can read the source on GitHub etc. though!)
We all agree that there is established prior art whereby large, long-living projects have a need to clearly demarcate their public API, so users don’t get surprised when private stuff changes in a future release. Many such projects have their own custom implementation.
This PEP exists to offer such projects a standardized implementation that is more ergonomic than current approaches. I think the PEP should focus on the needs of greenfield projects rather than bend backwards on how to introduce this into an existing large project – each large project has its own ways of handling change, and we don’t want to tell them how to do. I an even see that some established projects won’t adopt export, and that’s fine.
I have a bikeshed with export <assignment>, but that can be discussed later.
My main gripes:
- The proposed warning is a horrible, horrible compromise that makes everybody unhappy. Let’s just make it an exception ExportError that inherits from both ImportError and AttributeError.
- The PEP needs to provide a mechanism for accessing internals from inside a package that doesn’t trigger warnings or errors. (Random idea: access to internals under the same toplevel package name is always allowed; internally this uses some package state that can be modified to specific other packages.)