Most recently created (I'm counting 20 years as recent) major languages do require or suggest that you specify the namespace a symbol is from if it isn't local.

Most recently created (I'm counting 20 years as recent) major languages do require or suggest that you specify the namespace a symbol is from if it isn't local. Off the top of my head, Javascript/Typescript, Python, Go, Java, I think it's good practice in Ruby but I'm not positive. I think C is the only major language I can think of off the top of my head that doesn't suggest namespacing symbols. > Asking the programmer to make a manual list for you really isn't reasonable, IMO. I prefer the clarity, it's worth my time. In the same way that most of the modern tooling will handle resolving which symbols are from which packages, most tooling will also handle adding imports for you if you give it a namespace. I just have to carry the mental load of remembering which package has the symbol I need. It's not an issue most of the time because I usually either know the library well enough that I know the symbol and thus the package, or I don't and I have the docs up on a screen. There are insidious ways both that and the import all resolution can fail. One is if the symbol exists in more than one package. Then all of a sudden the ordering of your imports matters, which I despise. Another way the __all__ imports can fail in weird ways is if you upgrade a package and it stops exporting a symbol you use. Namespaced symbols will start throwing errors that the symbols doesn't exist in the package. __all__ imports mean you now have to figure out where that symbol even came from originally. You can check what got upgraded and go backwards from there, but it's going to confuse junior devs and your DevOps people. There might also be performance implications. I don't know if Python has the ability to avoid parsing unused parts of modules or not. It's probably generally negligible unless you're writing small CLI tools.