On Wednesday, March 16, 2016 at 9:19:52 PM UTC-5, David Wilson wrote:
On Wed, Mar 16, 2016 at 06:58:55PM -0700, Rick Johnson wrote:
> I avoid __all__ like the plague. Too easy for it to get out of sync with the
> API when i forget to add a new symbol.
In that case why not simply also avoid 'from .. import *' like the
It seems far simpler than renaming every single import, which
places a permanent burden on future maintainers, code completing
editors, grep, etc.
Oh, i understand your confusion now. You think i'm importing *EVERY* symbol this way. No, i'm only importing the symbols i need. And, just FYI, not all modules exist as a "top level component". Many times, you need to split parts of a "component hierarchy" across multiple modules, with each module in the "chain", building upon the last, to create a complex system, that is greater than the sum of all it's parts.
For instance: I might start with a "base module" that exposes a few public symbols. Granted, the module may have many private variables, but it only exposes a handful to the public. If i then "inherit" from that module, and "extend it", the symbols that i import from the first module may have made sense to be public in the first module, but now, in the new module, they are merely sub-components of a larger interface, and should therefore be private.
(i use the terms "extend", and "inherit" very loosely here)
If i simply wanted *ALL* the pubic symbols, and the module i was importing *FROM* followed the Python style guide by using a single underscore for private symbols, then "from module import *" is the way to go -- because i would *ONLY* receive the public symbols.
FWIW I'd probably _break _down _and cry _if _faced _with _maintaining
_code _like _that.
This reminds me of a funny story. I once told my doctor "When i do this, it hurts". And you what he told me? He said: "Well, don't do that"