On Tue, Mar 30, 2010 at 12:44 AM, Gary Bernhardt <[email protected]> wrote: > On Mon, Mar 29, 2010 at 8:34 PM, Ingy dot Net <[email protected]> wrote: >> >> Thanks. Actually it does pollute the global namespace a bit, with the key > > Ahh, this is a different issue. Before, we were talking about not > polluting, but what you're really talking about here is total control. > For that, you want to define __all__ in your module. It's a list of > strings; only those strings will be visible from the outside. > > However, I've found that, in general, anything useful to the module > might be useful to the outside, and you probably should just expose > it. Why not just expose main, for example? What if I want to wrap > PyPlay, doing some sort of magic and then calling your main function? > Seems reasonable to me! > > The only time I use __all__ is when I'm writing a top-level API module > and simplicity is very important – in my Expecter Gadget library, for > example.
I halfheartedly use '__all__' in public libraries, especially if people are likely to "import *" them (as is the case with WebHelpers subpackages). But it can be difficult to decide whether to put only your main public objects in there, or everything which is safe to use and might be useful for something unexpected. What you really want is to declare a hierarchy of public-ness, but '__all__' is only two-level. There's also the overhead of remembering to update '__all__', and to think about what might need to be exposed. Exceptions tend to be the biggest oversight. If you define an exception, you may think that its only purpose is to make the traceback more descriptive and so the caller has no need to access it directly. But they may want to put it in an 'except' clause, so it should be exposed. However, I've come to the conclusion that "import *" produces hard-to-read code, so I use it rarely. > Make? We don't use that around here! ;) (Well, except for building > Python itself...) I still suspect that there's a much easier way to > make "setup.py test" work, although I'm not motivated to find out what > it is. My projects always have a "runtests.py" file (e.g., [1]) that > invokes nose, because I like to configure things like test naming. I was going to say in my other rant, distutils/setuptools is not the Way to End All Ways either. Just because "python setup.py test" exists doesn't mean it was the best thought-out idea. Tarek Ziade has done some impressive development consolidating the best parts of distutils/setuptools/pip/distribute. This is now expected to be distutils updates in 2.7 / 3.2, and a distutils2 replacement in the following version. In the meantime, "python setup.py test" with Unittest, "python setup.py test" with Nose (there's an option to choose a test engine somewhere), and "nosetests" are all honorable. -- Mike Orr <[email protected]>
