Disclaimer: I have no problems with standard import philosophy.

TIL that I can both import nothing from a module and alias it; my previous attempts failed, and looked like this:

# Regardless of order, this imports all symbols from `foo` into the current namespace
# and allows for fully qualifying symbols from `foo` with either a `foo` or `f` prefix.
import foo as f
from foo import nil

My latest attempt works and approximates what imports are like in Python.

# This imports foo as f and requires fully qualifying symbols from `foo` using the `f` prefix.
from foo as f import nil

I think that's pretty nifty, even if I don't end up importing things that way.

2017-09-08 15:18:41

import X is broken design in general. :< It works the same as in Fortran, one of the best practices of which is "never use use without only:". ^^" It seems to me it would be much better if import X would not pull anything into global scope and from X import * (or something similar) imported all the stuff.

Anyway: nice trick, I haven't had a need for something like that yet...

2017-09-08 19:44:53

Hi Jester, Thanks a lot for the tip. Today I started to get name conflicts on autogenerated imports. I have macro that scans all nim files and imports those that have tests in them.

So now I am generating :

from foo as ("t" & $i) import nil
where i is the index in seq of module names and it works perfectly

2017-09-12 09:45:40
I am interested in what conflicts you have, so that you really want to use the from foo import nil pattern. I had conflicts, too. But I never thought about using that pattern. Because even if there is a name conflict, it does not break the import I just have to be more specific for that name conflict.
2017-09-12 10:38:57
Wouldn't it generate conflicts if trying to import two modules with the same name? Like strutils and jvm.strutils for example?
2017-09-12 11:31:41
I have two nim files with identical names in different folders and there is a good reason why they are called the same. I am collecting all tests across all modules into one executable. 2017-09-12 12:16:57


# Both provide baz(x:int)
import foo
import bar

proc main =
  # No conflict if the code doesn't use baz.
  # Unqualified use of baz causes an error because it is ambiguous.
  # baz(1)
  # Qualified uses of baz are fine.

My experience may not be representative, but the libraries I use don't have broad symbol overlap, just a few. In those cases I add the extra qualification and go on my way.

2017-09-22 14:18:36

@jester I said two modules with the same name, not just two modules that provide two things with the same name. More like:

import graphics.settings
import sounds.settings

sth_they_share()           # error: which one?
settings.sth_they_share()  # error: which one?

2017-09-22 17:06:04