On Sun, Mar 28, 2010 at 5:57 PM, Gary Bernhardt <[email protected]>wrote:
> On Thu, Mar 25, 2010 at 3:52 PM, Ingy dot Net <[email protected]> wrote: > > On Wed, Mar 24, 2010 at 3:06 PM, Gary Bernhardt < > [email protected]> > > wrote: > > >> - "del"ing local variables at the end of a function doesn't do > >> anything; it just destroyed the local reference, which would've been > >> destroyed when the function returned anyway. > > > > Actually it does do something in this case. When I ran the command: > > > > >>> y(globals()) > > > > inside pyplay, it showed the 'command' variable, which is an internal > detail > > that the user doesn't need to know about. I get your point in general > > though. > > I was referring to the "del"s in the (unused) init_readline_TODO > function. The "command" variable you del at the very end of the file > will indeed show up in the module's globals because the "if" is at > global scope. What you really want is to define a main() function > above the if with all that code in it, then just say: > > if __name__ == '__main__': > main() > > This will do exactly what you want and never pollute the global > namespace. (I should've included this in my original feedback but it > slipped by. :) Thanks. Actually it does pollute the global namespace a bit, with the key 'main'. I tucked main away under the PyPlay class and did this instead: if __name__ == '__main__': PyPlay().main() I had to then export my 'h' and 'y' functions by hand with globals().update(...) Then I noticed more pollution: 'Config'. I put my Config class as a class definition _inside_ PyPlay. I still have this: >>> y(globals()) --- PyPlay: !!python/name:__main__.PyPlay '' __builtins__: !!python/module:__builtin__ '' __doc__: 'The ``pyplay.py`` module supports the ``pyplay`` command line utility. ' __name__: __main__ __package__: null __version__: '0.7' h: !!python/name:__main__.h '' y: !!python/name:__main__.y '' >>> Can I get rid of __doc__, __version__, etc? BTW, init_readline_TODO was just some readline invoking code that I found on the web. I pulled it out for now. > OK, about the testing. I fixed all your findings in just a few minutes but > > then spent the rest of the night trying to figure out python testing. I > > wanted to make it so that the tests would run with `make test`. I have a > > tiny Makefile that proxies targets to setup.py, so that would also be > > `python setup.py test`. > > > > It drove me to fits, and I would love some pointers here. > > > > You can see how I did it, but it's not particularly pretty. I didn't even > > use unittest or py.test or nose yet. Just an assert. I couldn't figure > out > > how to invoke the framework tests from setup.py. And adding the 'test' > > command to setup.py took a lot of code. Thought it would be zero or one > > lines. :) > > I've never bothered with the "python setup.py test" stuff, but it > seems like there should be some easier way to make it work. Sorry; I'm > no help there. > I got it to work! I'm pretty proud of my self because I had to dig into the unittest.py module and figure out how to invoke tests from within another module. Here's what I came up with: for test in glob.glob('tests/*.py'): name = test[test.index('/') + 1: test.rindex('.')] module = __import__(name) module.unittest.main(argv=['']) You can see the whole thing in my latest setup.py. Hopefully I can refactor it over time to something simpler, but at least I have it working now. > However, if you just make your "tests" directory a package (i.e., > create a file tests/__init__.py), and name your test functions > test_whatever (or your test classes TestWhatever), then you can just > run nosetests at the root and it'll do the right thing. It traverses > the packages it can see, collecting anything that looks like a test, > then runs them all. > 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. I have a project called TestML that is a programming language agnostic unit test language. I'll be talking about it (along with C'Dent) at the upcoming meeting. Cheers, Ingy 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
