On Jul 23, 2019, at 12:02, Steve Dower <steve.dower@python.org> wrote:
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.
If we were to adopt @public, its inclusion in the stdlib would follow the precedence we already have for non-functional changes (e.g. whitespace, code cleanup, etc.). It definitely shouldn’t be done willy nilly but if the opportunity arises, e.g. because someone is already fixing bugs or modernizing a module, then it would be fair game to add @public decorators. Of course, you can’t do that if it’s not available. :)
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).
Agreed, sort of. We’ve had lots of cases of grey areas though, where the documentation doesn’t match the source. The question always becomes whether the source or the documentation is the source of truth. For any individual case, we don’t always come down on the same side of that question.
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.
+1 -Barry