The alternative is what exactly? Have the entire standard library exposed at once? Make all modules create non-conflicting names for exported objects, so that the json parse function has to be called json_parse and the csv parse function has to be called csv_parse?
Seems less than ideal to me.
If these things are classes in a plain old single-dispatch oop system, you can havec a json-parser and csv-parser which have parse methods.
There could be packages/namespaces. So csv:parse and json:parse. These packages are standard and so they just exist; nothing to import.
In Python, you cannot use anything without an import! The top-level modules (which serve as de facto namespaces) themselves are not visible.
Say there is a csv module with a parse. You cannot just do:
csv.parse(...)
import csv
I will not Go lang has the same feature carried forward from C. It helps a lot in the reading code side of the code lifecycle. And Go compiler makes you keep the imports up to date, which is good.
It lets you debug Python problems which the system created in the first place.
> If they have some weirdly screwed up paths with multiple pythons installed and multiple copies of the modules etc., same.
Doesn't happen in a sane language. Or, even not a sanely defined language/implementation.
I can easily have multiple different GCC copies (possibly for different processor targets) on the same machine. Each one knows where its own files are; an #include <stdio.h> compiled with your /path/to/arm-linux-eabi-gcc will positively not use your /usr/include/stdio.h, unless you explicitly do stupid things, like -I/usr/include on the command line.
It can be slightly inconvenient but doesn’t feel moronic to me. It means that except for the built-in functions, everything can be traced to either a definition or an import. Makes tracking code much easier.
from python import def # now you can def