Also see the log of Ideas and Successes

Overview of the reimport process

The reimport process is handled in several steps.

• A list of modules and packages are given to be reimported.
• For each module, we check all parent packages for a package_reimport value. If the value is True we will reimport the entire package, instead of just the submodule.
• Build a unique set of final modules and packages to reimport. Sort them by package depth order.
• Check each module for SyntaxError and early exception out.
• Move all packages to be reloaded out of sys.modules and hang onto them.
• Reimport modules one at a time. Check to make sure it hasn't already been imported from a parent package being reimported.
  • If module added values to all that are missing, AttributeError is raised and reimports are rolled back.
• Find reimported callback and pass the old module reference as an argument
  • If callback returns False, do not perform the rejigger for that module
  • Exceptions from the callback are redirected to traceback.print_exc
• Find parent packages that haven't been reimported that appear to import * (change for 1.1)
  • Push exported symbols from children into these parents (change for 1.1)
• Begin rejigger process for each module imported
  • Match old objects to new objects by name
  • Transmute classes and functions in the module from old to new
  • Switch references from the old object to the new
  • For lists, sets, and dictionaries this isn't tricky.
  • For tuples it is trickier, but an attempt is made to build a new tuple, and swap references to the tuple itself.
  • Classes that derive from the old object have their bases modified.
  • Instance have their class swapped
  • Remove references to old objects that have no matching named object
  • Similar process to the above reference switching
  • Note, this doesn't seem to find bound methods to a method that gets dropped
    • My first guess is that the gc doesn't track bound methods? (surprising)