Presumably you are referring to the way imports are done in Nim, i.e. the fact that all symbols are imported into the current module by default (the equivalent of `from module import *` in Python). Nim could certainly follow Python's lead, but that would limit the language: Nim supports UFCS and operator overloading which requires modules to be imported this way.
You can of course feel free to use `from module import nil` in Nim to enforce module name prefixes for each procedure call. But keep in mind that there is no risk of ambiguities, the compiler statically checks everything and refuses to compile your code if there is an ambiguity (at which point you will need to resolve it by prefixing with the module name).
I would be interested to hear more about other things that you think are a bad idea. Could you elaborate a bit?
I'm certain that almost everyone dismissed it due to its syntax (there are still people out there that dismiss it because of that).
The "killer app" then was an app server + document store called Zope.
Things were smaller than today, but Python was already gaining popularity for scripting. Circa 2001 or so it also had good Gtk and Qt bindings -- there were even some KDE-inspired satellite commercial companies catering to Python/QT.
The discussions in Python land then were about the mythical Python 3000 -- the next, re-imagined version of Python that would fix issues, etc. That was eventually Python 3.
Perl was still king for scripting/admin stuff but losing momentum, and Ruby was mentioned as a nice alternative to Python, but with much smaller use at the time (and even today I think).
Very small. The language was not popular and many people claimed a community project could not overtake languages backed by companies. Same for the Linux kernel.
I would actually love to read some forum/mailing list posts about this. If anyone has any links handy (or knows where to find them) then please post them.
So, bring 'em on.
https://trends.google.com/trends/explore?date=today%205-y&q=...