4 ms·

I've always thought "from lib import star" is somewhat of a anti-pattern. Personally I think that makes sense - because sometimes when I read code, I just have

• qbasic_forever 5y ago
  pep8 discourages it, but context matters. a half page readme example trying to demonstrate API usage succinctly is not the sames as a 10 year old 40k line codebase that 25 devs work on
• dragonwriter 5y ago
  > I've always thought "from lib import star" is somewhat of a anti-pattern Like patterns, anti-patterns are context sensitive. “from lib import *” is usually an anti-pattern, but doing it exactly once in a source file, especially a short one, and especially for demonstration code for the library so imported, is not a problem. But if you do it two or more times in the same source file...
• dbieber 5y ago
  Here's my take: Don't use "import-star" in library code. Like you say, it obscures where elements of the namespace came from. When using Python interactively, esp. if the interactive session is to be thrown away at the end, then import-star can be fine and can be a good time-saver. Video editing is a great example of when this is appropriate. See also manim. Other examples might be one-off html parsing or one-off data manipulation tasks. Similar to "import-star" is multiple inheritance. Just like import-star, multiple inheritance can make it ambiguous where methods come from, and imo it should similarly be avoided by default unless there's a compelling reason to use it.
  • pbourke 5y ago
    I don’t import-star in the console or notebooks (PyCharm, specifically) because autocomplete works better with the module to scope the search. So I end up doing a lot of aliased imports like “import numpy as np”
• detaro 5y ago
  An anti-pattern, but I think it's somewhat acceptable for one-offs, examples, ... where there is really only one thing it can come from.
• amelius 5y ago
  Side question: how do you prevent import statements from being imported by "from lib import star"? (Without explicitly mentioning all the stuff that is not import statements). For example, this is mymod.py: import numpy as np def f(x): return 2*x And here it is imported: from mymod import * f(10) # Works as expected. np.sum([10, 20]) # Works, but shouldn't work.
  • connorbrinton 5y ago
    The best you can do (without doing crazy introspection) is to set `__all__` in `mymod`. It still requires listing everything you want to be exported from `mymod`, but at least you only need to do it once. Docs: https://docs.python.org/3/tutorial/modules.html#importing-from-a-package https://docs.python.org/3/tutorial/modules.html#importing-fr...
    • formerly_proven 5y ago
      Linters will also complain about importing stuff that's not listed in a module's __all__, so it's overall good API hygiene to have one.
  • comradesmith 5y ago
    Python modules can define a list named `__all__` which of present will define the behaviour of importing “everything”. The `from x import y` syntax is unaffected
  • qbasic_forever 5y ago
    Any non-trivial python module is going to be broken up into multiple files and have an __init__.py which you can explicitly define what's imported and exposed. You can hoist a single file module into a folder-based module if you need direct control and don't want to split it apart into multiple files yet too.
  • ciupicri 5y ago
    You could use names starting with _ (underscore) for things that you don't want to export. Your module would look like this: import numpy as _np # numpy will be hidden def f(x): return x * 2 def _g(x): return _np.array([x, x]) # _g is a non-public function
• tclancy 5y ago
  No, you’re right. It’s like picking your nose. Don’t ever do it. I don’t ever do it. Unless no one can see. Somewhat more seriously, don’t do it in anything other than one-off code once you’ve experimented enough to get the result you want unless you aren’t scared of the people who will yell at you about circular imports.
  • ackbar03 5y ago
    You pick your nose? Ew! I never pick my nose!