4 ms·

What you describe as "wrong" is how a great many languages work. After coding nearly every day for over 30 years, across many languages, I've come to a view th

by jph00 6y ago

What you describe as "wrong" is how a great many languages work. After coding nearly every day for over 30 years, across many languages, I've come to a view that computers should do our work for us where possible, and that valuable programmer time should be spent doing the things that computers can't do for them. Most languages do not require the programmer to list every single symbol that they use at the top of the file, or expect programmers to read that entire list to figure out where a symbol comes from. Pretty much every modern editor, IDE, and live coding environment will do that for you. Asking the programmer to make a manual list for you really isn't reasonable, IMO. The reason that `import *` is dangerous in Python is that most people don't define __all__, and unfortunately Python doesn't have an easy way to avoid namespace pollution without that. Many in the Python community have now convinced themselves that's a feature.

curryst 6y ago
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.

by jph00 6y ago

curryst 6y ago

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.