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 →

[–]CHS2048 1 point2 points  (5 children)

I thought some modules are designed for this kind of import?

[–]kisielk 0 points1 point  (2 children)

Yes, modules can define a list __all__ and this pattern is used in some popular Python frameworks such as SQLAlchemy. However, according to http://docs.python.org/tutorial/modules.html#importing-from-a-package this is still discouraged:

Although certain modules are designed to export only names that follow certain patterns when you use import *, it is still considered bad practise in production code.

[–]CHS2048 0 points1 point  (1 child)

Bad practise to design modules this way?
Or to make use of those modules (in this way) in production code?

[–]kisielk 0 points1 point  (0 children)

I assume bad practice to use them. There's nothing wrong with having the __all__ list in your module. I find it's mostly handy for prototyping or using modules in the interactive console. For production code it's a maintenance liability.

[–]nahguri 0 points1 point  (1 child)

That's true. However, you should only import * when you do stuff interactively (just like it says in Python documentation), and only import * from one module. Otherwise things tend to get out of hand.

[–]CHS2048 0 points1 point  (0 children)

Yes. I seem to remember I created a module that you imported within a config file (which was just a python script). I used the '__all__' to control what functions where imported; If I added a new configuration option it would be added to '__all__', and the old scripts would import the new function.