homepage

I built a C extension using SWIG for both Python 3.2 and Python 3.3. The Python file supplying class proxies uses imp.load_module and fails with the following traceback on 3.3.0rc1, but works on 3.2.3:
 Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File ".\Widget.py", line 26, in <module>
 _Widget = swig_import_helper()
 File ".\Widget.py", line 22, in swig_import_helper
 _mod = imp.load_module('_Widget', fp, pathname, description)
 File "D:\dev\python33\lib\imp.py", line 171, in load_module
 raise ImportError(msg, name=name)
 ImportError: Don't know how to import _Widget (type code 3
It looks like imp.py is new in Python 3.3, and imp.load_module no longer supports the C_EXTENSION type. It looks like a regression.
To reproduce, I was able to run the following lines with the .pyd file in the current directory:
 import imp
 fp, pathname, description = imp.find_module('_Widget')
 imp.load_module('_Widget', fp, pathname, description)
Nit: Also note the missing final ')' in the ImportError message.

An even easier reproducer:
>>> import imp
[93559 refs]
>>> details = imp.find_module("_elementtree")
[93572 refs]
>>> mod = imp.load_module('_elementtree', *details)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/home/ncoghlan/devel/py3k/Lib/imp.py", line 171, in load_module
 raise ImportError(msg, name=name)
ImportError: Don't know how to import _elementtree (type code 3
[93572 refs]

Patch adds test case and fix (there was simply a missing entry for C_EXTENSION/load_dynamic in the load_module if-elif chain).
Also moves an imp module test from test_import to test_imp (it's the test I used as a guide to check I wasn't missing anything obvious when writing the new one).

Tweaked patch to also fix the typo in the error message

I'm heading to bed, so whoever reviews this one, please feel free to add a NEWS entry and check it in :)

LGTM

Since I'm still up, I guess I'll check it in, then :)

New changeset 9ba57938f54d by Nick Coghlan in branch 'default':
Issue #15828: Restore support for C extension modules in imp.load_module()
http://hg.python.org/cpython/rev/9ba57938f54d 

Over to Georg to cherry pick this one into rc2

New changeset d54f047312a8 by Brett Cannon in branch 'default':
Issue #15828: Don't try to close a file if imp.find_module() doesn't
http://hg.python.org/cpython/rev/d54f047312a8 

Picked as 4f6f59303146 and a4a9c5717204.

New changeset 4f6f59303146 by Nick Coghlan in branch 'default':
Issue #15828: Restore support for C extension modules in imp.load_module()
http://hg.python.org/cpython/rev/4f6f59303146
New changeset a4a9c5717204 by Brett Cannon in branch 'default':
Issue #15828: Don't try to close a file if imp.find_module() doesn't
http://hg.python.org/cpython/rev/a4a9c5717204 

The applied fix appears to have a regression - the file argument is not allowed to be None. The pywin32 post-install script calls imp.load_module for a C extension with file=None, so presumably this worked in earlier versions.
The regression breaks the postinstall script for pywin32, meaning that the start menu shortcuts do not get installed. I do not know if it has any more serious consequences for pywin32.

Paul, are you using the hg tip of pywin32? pywin32_postintall.py was
patched a couple of months ago to use imp.load_dynamic (essentially to
work around this issue).

On 10 September 2012 11:47, Tim Golden <report@bugs.python.org> wrote:
>
> Tim Golden added the comment:
>
> Paul, are you using the hg tip of pywin32? pywin32_postintall.py was
> patched a couple of months ago to use imp.load_dynamic (essentially to
> work around this issue).
No, this is the 217 release. Looks like they may need a new release then...
Paul

Paul, could you please report that issue/question separately? If it's a
regression, it's likely in the importlib migration in general and was
hidden by this bug rather than being introduced by the fix.

Logged as #15902.