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. > Thanks. I think __all__ only affects what happens when you `from foo import *`. pyplay is a little bit weird because you don't typically import it. It is really just run as a PYTHONSTARTUP script by the 'pyplay' bin script. So using `__all__ = []` doesn't help me towards the goal of keeping the globals() dict clean. In fact, it actually "adds" __all__ to my globals! The only thing I can do is move everything inside the PyPlay class. I realize that this is all just silly conjecture and not very important... but if I wanted to push it... what could I do to make pyplay startup be as close to plain python startup as possible, while still adding the pyplay helpers? If I start python I get: >>> globals() {'__builtins__': <module '__builtin__' (built-in)>, '__name__': '__main__', '__doc__': None} If I start pyplay I get: >>> globals() {'__builtins__': <module '__builtin__' (built-in)>, 'h': <function h at 0x6317b0>, 'PyPlay': <class __main__.PyPlay at 0x630810>, '__package__': None, 'sys': <module 'sys' (built-in)>, 're': <module 're' from '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/re.pyc'>, 'y': <function y at 0x631870>, '__name__': '__main__', '__version__': '0.8', 'os': <module 'os' from '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.pyc'>, '__doc__': 'The ``pyplay.py`` module supports the ``pyplay`` command line utility.\n'} So let's see... I'm fine with the standard: __builtins__, __name__ and __doc__ I want the pyplay additions: h, y, os, sys and re I guess I'm ok with the PyPlay module in globals, but it's not useful to the user. The only other thing to get rid of is __version__. I think I'll need 'del' to get rid of those... 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! > It's not like 'main' is gone. It's just not exported. Correct me if I'm wrong, but I think you can still access everything in a module when __all__ is set to []. Right? > > 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 want to learn unittest since it is core. Now I can tell people to run > > 'python setup.py test' or simply 'make test' and it will always do the > right > > thing. > > 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. :) Make is just for my own typing sanity. My Makefile simply proxies all its targets to setup.py. I really just want all these things to work: setup.py build setup.py test setup.py install > > PS. It turned out the setup.py only ran the first test, if I had multiple > > tests. That is because unittest calls sys.exit!! That seems evil to me. I > > was overjoyed to find out I could work around this with even more evil. I > > added this to my setup.py: > > def exit(code): > > pass > > sys.exit = exit > > :-D > > OH GOD KILL IT WITH FIRE! > XD Ingy > > [1] http://bitbucket.org/garybernhardt/dingus/src/tip/runtests.py > > -- > Gary > http://blog.extracheese.org >
