What do you think of PEP 842's module exports proposal?

I like the idea of making a library's public surface explicit. In a large package, having to alias imports with leading underscores just to keep the interface tidy gets annoying. A clearer boundary could also discourage accidental dependencies on implementation details.

That said, the benefit depends on how the feature works in practice. Making the intended interface visible is useful. Making internals impossible to reach is a separate and more contentious choice.

I don't see enough justification for a new mechanism. A package can put implementation code in internal modules and expose a smaller public interface from separate modules. The __all__ attribute and underscore conventions already communicate intent, too.

Those approaches aren't identical to enforcing exports, but the extra complexity needs to buy something substantial.

Please don't turn an internal marker into a locked door. Sometimes a library doesn't expose the hook an application needs, and being able to reach inside is useful even when the code might break after an update.

An explicit warning or tooling check sounds much better to me than having to ask the library author for permission.

There's a maintainability argument here that goes beyond hiding names. Library authors need to know which interfaces they can change, and application developers need some indication of what they can reasonably rely on. Explicit exports could help with that distinction in larger codebases.

One point in favor is consistency between native extensions and Python code. Extensions can already control what they expose, so giving Python modules a way to express a similar boundary is worth considering, even if the details are debatable.