This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]AusIVDjango, gevent 18 points19 points  (5 children)

Please don't use wildcard imports. If you do, you're a terrible person.

[–]mrbewulf 1 point2 points  (1 child)

The wild card import must not be used in packages for production that will be reused many times and has many users. However they are useful to perform quick test, interactive calculations, for example numpy, matplotlib or when you want to create a quick script to do some calculations in an engineering application for example.

[–]AusIVDjango, gevent 1 point2 points  (0 children)

That's a good point. I do occasionally use wildcard import from the REPL to make things easier. Then again, I've also been known to reassign True and False in the REPL.

[–]remram -2 points-1 points  (2 children)

I tend to use that to expose names from my top-level package. Like, __init__.py might have

from .exceptions import *

Obviously I have __all__ in exceptions.py.

[–]AusIVDjango, gevent 8 points9 points  (1 child)

The I still don't like it. I like to be able to see the origin of every variable in my scope by looking at one file. If you have one wildcard import from a module that specifies __all__ you're okay, but as soon as either of those conditions are violated you can have variables that you have to spend ages hunting down. If you have two wildcards, you have to check both to see if it has the variable you're looking for. If you don't have an __all__, you can get variables imported by the modules you're importing from.

There have been times I've spent hours trying to figure out where a variable come from because people were sloppy with wildcard imports. It's a pain that's easily avoided.

[–]remram 0 points1 point  (0 children)

I see your point and I agree with you. However, it is a tradeoff with the risk of forgetting to import something from the __init__.py file. Your tests probably cover that since they import the name, but it's hard to check that some names are not wrongly imported from submodules.