[Python-Dev] Fix import errors to have data

Tim Peters tim.peters at gmail.com
Sun Aug 1 01:32:04 CEST 2004


[Guido, patches PyImport_ExecCodeModuleEx to remove a non-pre-existing
 module from sys.modules if executing the module code raises an exception]

It fixes at least one spurious -r test failure on Windows.  Before:

$ regrtest.py -uall test_sundry test___all__
test_sundry
test___all__
test test___all__ failed -- Traceback (most recent call last):
  File "C:\Code\python\lib\test\test___all__.py", line 150, in test_all
    self.check_all("rlcompleter")
  File "C:\Code\python\lib\test\test___all__.py", line 40, in check_all
    "%s has no __all__ attribute" % modname)
  File "C:\Code\python\lib\test\test_support.py", line 208, in verify
    raise TestFailed(reason)
TestFailed: rlcompleter has no __all__ attribute

After:

$ regrtest.py -uall test_sundry test___all__
test_sundry
test___all__
All 2 tests OK.

It does not fix at least one other one, because a second attempt to
import curses still "works" on Windows:

>>> import curses
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Code\python\lib\curses\__init__.py", line 15, in ?
    from _curses import *
ImportError: No module named _curses
>>> import curses
>>> curses
<module 'curses' from 'C:\Code\python\lib\curses\__init__.pyc'>
>>>

So whatever this patch does <wink>, it breaks down somehow for
non-importable packages.  I guess that any path thru import.c calling
PyImport_AddModule() before calling PyImport_ExecCodeModuleEx() will
suffer similarly (because the former convinces the latter then that
the module "is pre-existing", even if it really wasn't, and the latter
won't remove it from sys.modules then despite that running its code
fails).

It breaks this Zope3 doctest twice, for an obvious reason:

def test_bad_import():
    """

    >>> c = config.ConfigurationContext()

    >>> c.resolve('zope.configuration.tests.victim.x')
    Traceback (most recent call last):
    ...
    ConfigurationError: Couldn't import zope.configuration.tests.victim,""" \
                                       """ No module named bad_to_the_bone

    Cleanup:

    >>> del sys.modules['zope.configuration.tests.victim']
    >>> del sys.modules['zope.configuration.tests.bad']

    """

That is, this test's cleanup currently requires that insane modules
get left behind.

It also breaks this Zope3 test, which uses a custom import hook:

ERROR: test_reporting_exception_during_import
(zope.importtool.tests.test_hook.HookTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Code\python\lib\unittest.py", line 260, in run
    testMethod()
  File "C:\Code\ZopeX3\src\zope\importtool\tests\test_hook.py", line
198, in test_reporting_exception_during_import
    import error
  File "C:\Code\ZopeX3\src\zope\importtool\hook.py", line 72, in importhook
    v = self.previous(name, globals, locals, fromlist)
KeyError: 'zope.importtool.tests.error'

self.previous there appears to be bound to __builtin__.__import__.   I
don't understand this code, but expect it's shallow to someone who
does.

Overall, I'm +1, but think it needs more work to plug the "curses on
Windows" kind of hole.


More information about the Python-Dev mailing list