[IPython-user] Autoreload (Re: Food for thought on python and interactive work

Pauli Virtanen pav@iki...
Sat Jun 7 08:26:27 CDT 2008

(Another try at sending this; sorry about the spam if this appears
multiple times...)

Tue, 03 Jun 2008 10:39:58 +0200, Johann Cohen-Tanugi wrote:
> ok thanks! (I know the usual way but having it readable together with
> the reminder is a plus :) )
> and I think that indeed Yosef Kreinin would pull his hair off his head
> reading the caveats below : these are more or less exactly the reason
> for his rant.
> So it is probably a good canton to drill through as far as
> possible....
> dreload?
> %autoreload?
> Enthought solution?
> And one stupid question, which should probably be directed to another
> list : why are attempts to fix the problem considered the job of 3rd
> party software and not of python core?

I noticed that I had broken Thomas Heller's superreload in
ipy_autoreload so that it functioned exactly like an ordinary reload.

A patch fixing this is here:


What superreload now does (ie. hence the "super") is that it upgrades
the code objects of all old function objects in the module after
reloading. This makes eg. the following to work:

>>> %autoreload 1
>>> %aimport foo
>>> from foo import baz, SomeClass
>>> c = SomeClass()
>>> baz()
>>> c.baz()
[edit foo.py and change baz and SomeClass.baz to print "BAR"]
>>> baz()
>>> c.baz()

Technically, this is implemented by collecting weakrefs to objects
previously in the module before reloading, then reloading the module,
and finally going through the list of references and replacing
obj.func_code with that from the new version in the module.

superreload now also clears the module's __dict__ before reloading, so
that old objects are not left hanging around there.

Replacing code objects is not bulletproof: I don't eg. see a way to
handle the cases where a method in a class is replaced by a property or
a variable so that old objects work like new ones.

The new set of (known) caveats are:
    - Replacing code objects does not always succeed: changing a
      in a class to an ordinary method or a method to a member variable
      can cause problems (but in old objects only).
    - Functions that are removed (eg. via monkey-patching) from a module
      before it is reloaded are not upgraded.
    - C extension modules cannot be reloaded, and so cannot be

There may be others lurking, though.

Maybe combining the above with dreload would bring reloading still
closer to the ideal...

Pauli Virtanen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digitaalisesti allekirjoitettu viestin osa
Url : http://lists.ipython.scipy.org/pipermail/ipython-user/attachments/20080607/90cdb1a7/attachment.bin 

More information about the IPython-user mailing list