I sympathize with @perfecto25 on global imports. They make a new codebase hard to learn because it's never clear where anything was actually defined.
I usually start with `from foo import nil`. When needed, I add specific symbols, e.g. `from foo import []=, %, ...` And eventually, at least for standard modules, I might end up importing an entire module here and there. However, there is a very good reason for the Nim default, as @mratsim says: "unified call syntax". In C++, you often call `instance.method(x, y)`. With that syntax, `instance` is an implicit extra argument to `method(this, ...)`. I'm not sure that's good style, but everyone is used to it by now. Nim _allows_ that, but it also allows `method(instance, x, y)`, which is more explicit. And in Nim, they are synonymous. This "unified syntax" has subtle advantages (which I won't describe here). If you did not import "method", then you must specify the module, `mymodule.method(instance, x, y)`. In that case, the "instance.method()" syntax would not work at all. Also, Nim templates are powerful and convenient, but they often expect you to have imported the necessary symbols already. As a result, if you use a temple from some other module, you need to know the _implementation_ of the template so that you know what you need to import. You can usually learn these from compiler warnings, but it's often easier to import globally and be done with it. So this "problem" with Nim imports is actually a result of _features_ of Nim that are generally not available in other languages.
