The way it handles imports is weird. Default to importing everything from the module without qualification? I know you can choose to qualify everything, but that seems to go against the language's conventions.
Using fully qualified imports is a Python tradition.
Python doesn't have a notion of public/private symbols (no, "__" prefix does absolutely nothing). It also doesn't have a good type system, so it can't have function overloading.
This is why you're required to qualify almost all imports in Python, to avoid name clashes.
Nim doesn't have this problem and also "fixes" a lot of other shortcomings[1] of Python.[2]
It's not only a Python thing. Many modern languages require this as well. Go, Gleam, Rust, etc.
When you're reading Nim code and you see a symbol you don't know, how can you tell where it comes from? In Rust, it's either qualified or you have to explicitly import it. What do you do in Nim?
> Many modern languages require this as well. Go, Gleam, Rust
All the languages you listed do not support function overloading. Qualified imports and namespaces exist to avoid name clashes first, dependency tracking is just a bonus (and a chore).
Nim's import rules are part of its generalization of OOP's obj.foo()
syntax. That is, in Nim, you don't have to put "foo" in a specific
class, just set the first parameter of "foo" to the type of "obj",
and this only works if you don't have to qualify "foo" (similarly to OOP
languages...)
I don't see how Nim's import is necessary for that to happen. You can allow the user to specify items to import without the qualifier (like Python's `from lib import foo`), and the universal function call syntax would work, too.
That is allowed, with the exact same syntax as Python. But then you still lose the qualification so I don't see any benefits, it's just more boilerplate to constantly adjust, git conflicts to fight with, etc.