@coffeepot: Please don't make this a prefix vs. no-prefix debate. I may not have been clear but this is really not the purpose.
The problems were stated from the start: * _I, as a developer, don't want to ever think about interactions with other's code._ As you said, I can enforce anything I want in my own code. The problem is that in a language which took a similar path, this has become a mess as the number of packages grew. I cited quite a few such issues to make my point. I also clearly stated that this is clearly not a **limitation** of Nim as a language as we both said. I said that this is related to the defaults which shape the behaviour of a community. Ever heard about someone indenting incorrectly in Python or Nim? Me neither because the language enforces "good" behaviour. There might be some way to guarantee that whichever name I choose for a symbol, no one will open a Github issue asking for "a better name that does not interfere with package Foo". * _I, still as a developer, would like to get Python readability, if possible, in Nim._ (By that I mean useful "built-in" hints to understand the structure of the code if I ever have to read it in a limited environment) The "if possible" does mean that this shouldn't be done by sacrificing Nim's current convenience, precisely because the tools already work great so we should not get something worse just for the convenience of the ones who don't want to use the correct tools. That might not be possible, but if nobody thinks of it, it sure won't be. About things I stated above, I was merely realising that namespace prefixes may not always be more verbose and actually have some advantages. Actually, up until an hour ago, prefixing the names of a procedure (like wav_read) seemed a good idea to avoid the problem until I "said" it out loud. But I am well aware that forcing people to use explicit namespaces just won't work, especially with Nim!
