Re:The Trouble with __all__
by claxo on Thursday August 01, 2024 @04:14PM
(#41133100)
A direct benefit of using `__all__` at module A is better intellisense while editing files that imports A, if A has a small intended public API and many internal usage symbols.
[ Parent
| on HN ]
Re:The Trouble with __all__
by trainfromkansas on Thursday August 01, 2024 @04:45PM
(#41133427)
I just tried it and at least the autocomplete in IPython appears to ignore __all__ when suggesting possible imports. I haven't tried any other tools' autocompletes.
If module A has a small intended public API, you can structure it no matter how you want to achieve that. You can put those internal symbols behind their own object/class/module if you prefer.
Using `__all__` has one functional consequence, which is `from A import *`. Again, I would avoid * imports entirely, but if you want to try to curb possible downstream problems from users who do indeed use * imports, I would also prefer not defining `__all__` because it's extra boilerplate you have to maintain and can very easily be missed on future updates.