Barry Warsaw wrote:
This leads to the second problem, which is that it’s too easy for the __all__ to get out of sync with the module’s contents. Often a function or class is renamed, removed, or added without the __all__ being updated.
IMO, this seems to be the best part of the @public decorator, at least from a general user's perspective. Manually having to update __all__ anytime something is added, removed, or has its name modified adds an extra step to easily forget. Also, those coming from other languages would be far more likely to recognize the significance of @public, the primary purpose of the decorator is quite clear based on it's name alone. Barry Warsaw wrote:
My package has a C version. If public() were a builtin (which I’ve implemented) it wouldn’t have that much import time overhead.
Is there a way we could estimate the approximate difference in overhead this would add using benchmarks? If it's incredibly trivial, I'd say it's worthwhile in order to make the public API members more explicitly declared, and provide a significant QoL improvement for maintaining __all__. While we should strive to optimize the language as much as possible, as far as I'm aware, Python's main priority has been readability and convenience rather than pure performance.