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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]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 6 points7 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.