views:

162

answers:

4

I am developing a Python package using a text editor and IPython. Each time I change any of the module code I have to restart the interpreter to test this. This is a pain since the classes I am developing rely on a context that needs to be re-established on each reload.

I am aware of the reload() fuction, but this appears to be frowned upon (also since it has been relegated from a builtin in Python 3.0) and moreover it rarely works since the modules almost always have multiple references.

My question is - what is the best/accepted way to develop a Python module/package so that I don't have to go through the pain of constantly re-establishing my interpreter context?

One idea I did think of was using the if __name__ == '__main__': trick to run a module directly so the code is not imported. However this leaves a bunch of contextual cruft (specific to my setup) at the bottom of my module files.

Ideas?

+2  A: 

Ipython does allow reloads see the magic function %run iPython doc

or if modules under the one have changed the recursive dreloadd() function

If you have a complex context is it possible to create it in another module? or assign it to a global variable which will stay around as the interpreter is not restarted

Mark
Using %run to load froma module is brilliant, thanks!
Brendan
The `dreload()` sounds also good but it seems to run into problems with Numpy - it also seems to ignore whatever I set in the `exclude` keyword list ...
Brendan
The problem with Numpy and `dreload()` is documented here https://bugs.launchpad.net/ipython/+bug/306805
Brendan
A: 

you could create a python script that sets up your context and run it with

python -i context-setup.py


   -i     When  a  script  is passed as first argument or the -c option is
          used, enter interactive mode after executing the script  or  the
          command.  It does not read the $PYTHONSTARTUP file.  This can be
          useful to inspect global variables  or  a  stack  trace  when  a
          script raises an exception.
Tanj
+3  A: 

A different approach may be to formalise your test driven development, and instead of using the interpreter to test your module, save your tests and run them directly.

You probably know of the various ways to do this with python, I imagine the simplest way to start in this direction is to copy and paste what you do in the interpreter into the docstring as a doctest and add the following to the bottom of your module:

if __name__ == "__main__":
    import doctest
    doctest.testmod()

Your informal test will then be repeated every time the module is called directly. This has a number of other benefits. See the doctest docs for more info on writing doctests.

Will Hardy
The advice to drive the development using *automated* tests (with the py.test or unittest modules, for example) deserves a +10, but I can give it only one. :(
Peter Hansen
That's also a good idea. However, the API is rapidly changing at the moment at these early stages. This is something that I would generally include later in the packages development.
Brendan
+1  A: 

How about using nose with nosey to run your tests automatically in a separate terminal every time you save your edits to disk? Set up all the state you need in your unit tests.

Ryan Ginstrom