On Sun, 29 May 2016 02:15 am, Gerald Britton wrote: > suppose I have a simple python project setup like this: > > Project diectory > prog.py > pkg directory > __init__.py > mod1.py > class A:
If this is a single project, why do you set it up like this? Is there a reason why you don't just have: prog.py # contains class A or even: prog.py mod1.py # contains class A Or if the project is so big it needs to be a package, make it executable: prog/ __init__.py mod1.py __main__.py This layout is now executable using: python -m prog which automatically calls __main__.py. But if you don't have a good reason for using a package, don't use a package. Use the simplest project layout that solves your problem. But for the rest of my comments, I'm going to assume that you DO have a good reason. > In order to have class A (unqualified) available from prog.py, there are a > few options that I know about. I'm currently considering two of them and > would like some feedback on best practices. > > 1. in pkg.__init__.py add: > > from pkg.mod1 import A This kinda-sorta defeats the purpose, or at least one purpose, of using a package. Which is fine, so long as you understand that's what you are doing. Generally speaking, one of the purposes of using a package layout is to allow unused sub-modules to be left unloaded unless needed. So pkg.mod1 doesn't get loaded unless you need it, in which case you explicitly call import pkg.mod1 or from pkg.mod1 import A as you prefer. By putting that import in the pkg __init__ file, you're making it automatically occur as soon as pkg is imported. Is that what you intend? If so, then it is fine, and feel free to do it. But in that case, why not just move class A into pkg/__init__.py? > in prog.py add: > > from pkg import A *shrug* This entirely depends on the purpose and use of pkg. When you give generic, meaningless names, I can only respond with wishy-washy, sit-on- the-fence generic advice. If the appropriate API is for callers to say: from pkg import A then this is the right way to design your package. But if the right API is: from pkg.mod1 import A then don't do it this way, instead do it as follows. > 2. leave __init__.py empty > in prog.py add: > > from pkg.mod1 import A > > > Is there a preference or best practice that would indicate to prefer > method > 1 or method 2? Are there methods 3, 4, 5, ... that I should consider that > are even better? One purpose of using a package is to have alternative implementations. For instance I have a package which has to support Python 2.4 where the "with" statement is not available, so I design it like this: package/ __init__.py module.py module24.py Since the user doesn't choose which implementation to use, I have this in the init file: try: from module import thing except SyntaxError: from module24 import thing and then the caller uses: from package import thing and is none the wiser. On the other hand, if the user was supposed to choose, then I would have then call: from package.redblack import Tree from package.avl import Tree from package.scapegoat import Tree and let the user choose which implementation they wanted. -- Steven -- https://mail.python.org/mailman/listinfo/python-list