Hacker News Reader

Comment by socratic | Hacker News Reader

Is there a standard set of tools that are being advocated here, in addition to the repository structure?

I've been mostly working with Rails lately, and I'd like to continue using tests, mocks/stubs, and sensible build rules, but I'm not sure what the preferred Python tools are. What's the best test::unit equivalent? What's the best way to mock an object? Do people really use Makefiles rather than something else (like SCons)? Is there some way to use virtualenvwrapper without bash (e.g., M-x eshell)?

View on HN

I use Make because it's fast, simple, always available, and bash has autocompletion for it, so I can type "make t<TAB>" to run my tests, for instance (or "make <TAB>" so see what commands I have available). I use make in my python projects for things like running tests, coverage, building the documentation (sphinx) and removing .pyc files.

For deployment I use fabric, but I have Make targets for the most used commands (again, it's nice to have completion). For example, these are two targets to deploy to my server and to my test machine:

    server-deploy:
            fab -f deployment/fabfile.py prod deploy

    test-deploy:
            fab -f deployment/fabfile.py test deploy

I use either pytest or nosetests to run my tests, mainly to have better and colored output.

I don't think you can use virtualenv(wrapper) without bash, but you can use use it with M-x ansi-term. But I got tired of trying to config emacs to run Python the way I wanted and now I edit my code an emacs and run the code in IPython in the terminal. Ipython's autoreload [0] is a huge help.

[0] http://ipython.org/ipython-doc/dev/config/extensions/autorel...

Why do you remove .pyc files?

When doing a large refactoring or removing modules all-together, leftover .pyc or .pyo files can cause some very hard-to-identify import errors.

    export PYTHONDONTWRITEBYTECODE=1

Make is better than SCons if you are not compiling C. Lots of people would use fabric instead. The stock unittest in the stdlib is quite good, especially in python 2.7+.

For mocks, wait until mock (http://www.voidspace.org.uk/python/mock/) is in the stdlib or download it yourself.

If you are on Python pre-2.7, the unittest2 (http://pypi.python.org/pypi/unittest2) library backports most of the unittest 2.7 features.

All activating virtualenv does is set up a bunch of environment settings (PATH, PYTHONPATH, etc). They provide activators for bash and csh; it wouldn't be hard to set up the environment for M-x eshell, even if it was a little more manual process.

Reply on news.ycombinator.com