Hacker News Reader

Comment by yuy910616 | Hacker News Reader

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 no idea where something comes from.

But I've seen import star everywhere, couple of examples:

Doc for this product

FastAI's course

Bing ads code base

So I'm guessing it is more of accepted than I expected? What does HackerNews think?

View on HN

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.

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”

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.

You pick your nose? Ew! I never pick my nose!

> 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...

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

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.

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-fr...

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.

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

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.

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

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.

Reply on news.ycombinator.com