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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/CYVVNNMRBDA53DZVLQDVBP5HCWO5FQSH/
