I’m perfectly fine with the __all__ variable.
I like the idea of @public and @private decorators for __all__ maintenance.
I like to put a (multiline, commented) __all__ variable near the top of my modules, resembling a nice table of contents, but I could continue to have this, and additionally use the decorators. They let me put the authorative information about being “public” right above the function / class definition.
Now for possible keywords, as suggested by PEP 842.
Let’s remember how C++ looks like:
private static void some_func() { ...}
PEP 20.1, “Beautiful is better than ugly.”
I consider this style ugly.
Why introduce a keyword if the task can be done by a decorator?
Instead of the static keyword, Python uses the @staticmethod decorator;
the use of public / private keywords would suggest more significance than we like to have in Python. It should always be possible to import a non-public name, even if marked private (or not marked public, or export-able).
It is not really private.
Decorators are pythonic.
An export keyword to start the line looks wrong to me. The class or function is defined here and exported nowhere (but imported elsewhere).
Furthermore, it would harm diffability and cause merge conflicts. Using a decorator, I can make a function @public or @private without affecting the (first) line of the signature.
A missing decorator might mean, “I have not decided yet”, or “RTFM”, or “I might add one once I feel like it.”
So, @public and @private decorators feel just right for the task of same-place maintenance of __all__; I don’t really care whether they are built-in or injected by atpublic[install].
I have no objections against the (re-) export keyword from PEP 843, which doesn’t affect function and class definitions; this does something a decorator cannot do, and it looks elegant.
So,
-1 for PEP 842
+1 for PEP 843
+0.5 for PEP 844