Mirror of forum.nim-lang.org

3744 :: [RFC] `import foo only bar` to mean `from foo import bar`

• timothee (orginal) [2018-04-11T22:29:58+02:00] view original

  This syntax seems easier to use:

  import foo only bar to mean from foo import bar rationale:

  • more in-line with other uses of import:

  import foo
  import foo except bar
  import foo only bar
  Run

  EDIT : or, without introducing a new keyword:

  import foo
  import foo : bar
  import foo : bar1, bar2
  import foo : nil
  import foo as foo2 : bar3 as bar3_alias, bar4
  Run

  • easier to switch between full import and restrictive import (simply append only bar)
  • easier to grep for (import bar would be be a false positive for searching for imports of module bar)

  I know it comes from python but IMO we can do better here (cf D's import foo:bar)

---

• mratsim (orginal) [2018-04-11T23:24:46+02:00] view original

  Sounds better for me too.

---

• Araq (orginal) [2018-04-11T23:35:14+02:00] view original

  Yeah ... not gonna happen. Yet another keyword, yet another micro improvement, yet another breaking change. Also misguided, in Nim only imports are quite useless because Nim splits procs and types for better or worse.

---

• Udiknedormin (orginal) [2018-04-12T11:06:12+02:00] view original

  Why useless? You could import someModule only x, y, z, pretty much like in, say, Fortran >=90. And it's not a breaking change, it's just not backward-compatible. A breaking changes make working code not working (or working another way), not enabling new things.

---

• mashingan (orginal) [2018-04-12T11:40:34+02:00] view original

  IMO, import foo only bar is weird, from foo import bar is read better

---

• dom96 (orginal) [2018-04-12T12:20:26+02:00] view original

  This doesn't need a keyword: import foo.bar

---

• Araq (orginal) [2018-04-12T13:34:09+02:00] view original

  import foo.bar already has a different meaning.

  I called it "quite useless" and I explained why I think that. Anyway, it's a minor point, not worth discussing.

  Once we have import x only y the same people who voted for it will tell me to deprecate from x import y because there should be only one true way to do everything as long as it's their way ( ;-) ) and then I will review PRs that fix the deprecated syntax into the new better syntax. Please accept that these things do have real costs.

---

• Udiknedormin (orginal) [2018-04-12T16:09:09+02:00] view original

  @dom96

  As much as I like import foo.bar, Araq is right, it has different meaning already. However, I'm not sure if it's a good practice to have a submodule named the same as one of the module's own entities so maybe it's fine to have two meanings to that?

  Well, I don't think from x import y should be depreciated just like do-notation shouldn't be depreciated just because we have =>. Both serve well and while I guess everybody has some preferences here (I prefer =>, for instance), it doesn't invalidate the other solution.

---

• timothee (orginal) [2018-04-12T20:07:31+02:00] view original

  > As much as I like import foo.bar, Araq is right, it has different meaning already. However, I'm not sure if it's a good practice to have a submodule named the same as one of the module's own entities so maybe it's fine to have two meanings to that?

  • language doesn't prevent it so we can't count on it, not worth the ambiguity of import foo.bar,
  • furthermore, import foo.bar, doesn't extend to importing more than 1 symbol bar1, bar2 from foo, unlike import foo only bar1, bar2

  So it would be:

  import foo
  import foo only bar
  import foo only bar1, bar2
  import foo only nil
  import foo as foo2 only bar3
  Run

  EDIT or without introducing a new keyword:

  import foo
  import foo : bar
  import foo : bar1, bar2
  import foo : nil
  import foo as foo2 : bar3 as bar3_alias, bar4
  Run

  and the pre-existing syntax would NOT be depracated.

---

• dom96 (orginal) [2018-04-12T20:40:15+02:00] view original

  Well, I don't think from x import y should be depreciated just like do-notation shouldn't be depreciated just because we have =>

  This is off-topic but I think do should be deprecated, mainly because it doesn't fit the language. I've been saying this for a while.

  ---

  Looking at this thread again I agree with Araq. from foo import bar matches Python, and we shouldn't have more than one way to do the same thing, especially at the cost of a keyword.

---