On 23Jul2019 1128, Kyle Stanley wrote:
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.
Even if the performance impact is zero, commits that span the entire codebase for not-very-impactful changes have a negative impact on readability (for example, someone will suddenly become responsible for every single module as far as some blame tools are concerned - including github's suggested reviewers). I'm inclined to think this one would be primarily negative. We already maintain separate documentation from the source code, and this is the canonical reference for what is public or not. Until we make a new policy for __all__ to be the canonical reference, touching every file to use it is premature (let alone adding a builtin). So I apologise for mentioning that people care about import performance. Let's ignore them/that issue for now and worry instead about making sure people (including us!) know what the canonical reference for public/internal is. Cheers, Steve