[Python-ideas] Proposal for an enhanced reload mechanism (original) (raw)

Peter Ingebretson pingebre at yahoo.com
Tue Oct 19 22:46:24 CEST 2010

(Sorry, I sent an html-formatted email by accident)

--- On Tue, 10/19/10, Chris Kaynor <ckaynor at 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-EaOJFqrL3PErO4okmHBlTeuw > > 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.

More information about the Python-ideas mailing list