One thing to keep in mind is that non qualified imports are essential for
(ad-hoc) polymorphism.
If I have a `seq` of floats I could map them by
import sequtils
let s: seq[float] = ...
discard s.map(proc(x: float): string = $(x + 1.0))
If later I decide that a different kind of collection will do
([vectors](https://github.com/unicredit/linear-algebra), [disk-based
sequences](https://github.com/andreaferretti/spills),
[lists](http://nim-lang.org/docs/lists.html), ...) I can keep the same code and
just import the relevant `map` implementation. The compiler will use the
correct overload based on the type of collection.
If instead one had used qualified imports
from sequtils import nil
let s: seq[float] = ...
discard sequtils.map(s, proc(x: float): string = $(x + 1.0))
one would have to change the last line to use the correct version of `map`,
much like OCaml does with `List.map` and so on (and in fact OCaml still does
not have ad-hoc polymorphism).
Many languages can do without this because the use dynamic dispatch
(object-oriented languages will use dynamic dispatch on the first argument
only, while if I understand correctly Julia will do dynamic dispatch on all
arguments and try to optimize this while jitting).
In Nim, dynamic dispatch is only used for methods, and relying on overloads of
static dispatch is fundamental to get this kind of polymorphism. (This is an
argument against `from sequtils import nil`, although `from sequtils import
map` would still do.)
As a second point (just to state the obvious) Python necessarily has to be more
conservative with imports because it does not have a static types mechanism
that allows the compiler to resolve such ambiguities with types.
I am not sure how Julia behaves with respect to this, but I am quite sure it
does not guarantee to resolve all types at compile time (although I think it
tries to deduce what it can). In any case, it may suffer from this issue more
than Nim because types are not fully determined ahead of time.
As a single data point, I don't use nimsuggest much: usually it is quite clear
what comes from where. I have never suffered with legibility trying to read,
say, Nim code on Github because of lack of tooling. I also don't care very much
about trying to come up with unique names - usually the types are unique enough
that this will not be an issue anyway, and if it happens final users are warned
of the ambiguity at compile time, so that they can qualify
