Error when scanning for modules with a different Python 3 version

Issue #22 resolved
Thomas Kluyver
created an issue

From this StackOverflow question

Digging in to debugging it, I can reproduce it, and I find that, on Python 3.3, it's trying to load scipy.lib.lapack.flapack.cpython-32mu. That comes about because the filename is an extension module (scipy.lib.lapack.flapack) for Python 3.2, but .so alone is also valid as a suffix.

_InternalImportModule checks first in a cache (_modules), which includes modules it has looked for and failed to find (represented as a None value). However, if it finds a None value in the cache, it doesn't set the error part of the return value, so the caller tries to use the None as a module.

The attached patch is a quick fix for this, but we should consider better ways to approach it. E.g. we could do away with the separate returnError field, and just check if module is None for a failure to find the module.

Comments (3)

  1. Thomas Kluyver reporter

    We could also check for valid module names before we attempt to load files (see _ImportAllSubModules). In this case, the . and - in flapack.cpython-32mu would have ruled it out.

  2. Log in to comment