Given the current (3.3) imp.py docstring
"""This module provides the components needed to build your own __import__ function.  Undocumented functions are obsolete.
In most cases it is preferred you consider using the importlib module's
functionality over this module.
"""
I wonder why it is being imported on startup. Is this an obsolete holdover.

---
The patch solves the problem of importing a non-existing load_dynamic, but
-        elif type_ == C_EXTENSION:
+        elif type_ == C_EXTENSION and load_dynamic is not None:
             return load_dynamic(name, filename, file)

With this change, an attempt to import a C_EXTENSION file will fall through to 
        else:
            msg =  "Don't know how to import {} (type code {})".format(name, type_)
            raise ImportError(msg, name=name)

Jeffery: does your m68k-atari-mint have no C_EXTENSION files, so that this will never be a problem? On my Windows system, _tkinter is one such, with the following outcome.

import imp
imp.load_dynamic
>>> imp.load_module('tk2', *imp.find_module('_tkinter'))
Traceback (most recent call last):
  File "<pyshell#13>", line 1, in <module>
    imp.load_module('tk2', *imp.find_module('_tkinter'))
  File "C:\Programs\Python33\lib\imp.py", line 164, in load_module
    return load_dynamic(name, filename, file)
TypeError: 'NoneType' object is not callable

Or is this not a problem because deprecated imp.load_module is never actually used?

___
Brett: by 'expected exception', do you mean the one above? or the one that is caught by the patch?

Another question: load_dynamic has a public name but is un-documented. Does that make it private enough that we can freely rebind it to None? Perhaps it does not matter since we are only doing this on machines where Python does not even start, so we won't disable a working imp.load_dynamic call if there is one somewhere (including the stdlib).

___
If imp.load_dynamic is private, then its import into imp can be removed once deprecated load_module is removed, making this issue moot.