The builtin reload function is very useful for iterative development, but it is also limited.? Because references to types and functions in the old version of the module may persist after reloading, the builtin reload function is typically only useful in simple use cases.
This is a proposal (pre-PEP?) for an enhanced reloading mechanism especially designed for iterative development:
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.
I have a patch against the current 3.2 branch that adds the gc.remap function (and unit tests, etc...) but not any of the additional reloading functionality. I have a separate prototype of the reloading module as well, but it only implements a portion of the proposal (one module at a time, and dicts/sets are not fixed up).
A few questions:
1) Does this approach seem reasonable?? Has anyone tried something similar and run into unsolvable problems?
2) Would there be interest in a PEP for enhanced reloading? I would be happy to rewrite the proposal in PEP form if people think it would be worthwhile.
3) Should I submit my gc.remap patch to the issue tracker?? Because the change to visitproc modifies the ABI I would like to get that portion of the proposal in before 3.2 goes final. Since the bulk of the change is adding one method to the gc module I was hoping it might be accepted without requiring a PEP.