(Sorry, I sent an html-formatted email by accident) --- On Tue, 10/19/10, Chris Kaynor <ckaynor@zindagigames.com> wrote:

...

This is a proposal (pre-PEP?) for an enhanced reloading mechanism especially designed for iterative development:

https://docs.google.com/document/pub?id=1GeVVC0pXTz1O6cK5mo-EaOJFqrL3PErO4ok...

The basic plan is to use the existing cycle-detecting GC to remap references from objects in the old module to equivalent objects in the new module.

What happens if you change the __init__ or __new__ methods of an object or if you change a class's metaclass? It seems like those types of changes would be impossible to propagate to existing objects, and without propagating them any changes to existing objects may (are likely?) to break the object.

Yes, this is a limitation of the approach.  More generally, any logic that has already run and would execute differently with the reloaded module has the potential to break things. Even with this limitation I think the approach is still valuable.  I spend far less time modifying __new__ methods and metaclasses than I spend changing the implementation and API ofother class- and module-level methods. The issue of old instances not having members that are added in a new __init__ is problematic, but there are several workarounds such as temporarily wrapping the new member in a property, or potentially the @reloadable decorator alluded to in the doc.