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.

▲

archargelod 4 days ago | parent | next [-]

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]

[1] - https://github.com/yugr/python-hate

[2] - https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programm...

▲

maleldil 3 days ago | parent [-]

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?

	▲	archargelod 3 days ago \| parent \| next [-]
		This is solved by tooling. LSP will get you to symbol definition in a single key press. That's a lot faster then looking it up manually. In my experience, it's even faster to git clone, open a project in neovim and navigate with LSP than browsing code with some online interface.
	▲	archargelod 3 days ago \| parent \| prev [-]
		> 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).

▲

shiomiru 4 days ago | parent | prev [-]

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...)

▲

maleldil 3 days ago | parent [-]

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.

	▲	shiomiru 3 days ago \| parent [-]
		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.