Only look one level deep for implicit relative imports

#59 Merged at b7d9624
  1. Thomas Kluyver

Fixes issue #94

Absolute relative imports only work in the current package, not parents of that package:

$ tree foo/
├── bar
│   ├──
│   ├── b.pyc
│   ├──
│   └── __init__.pyc
└── __init__.pyc

$ cat foo/bar/
import a

$ python -c "import"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "foo/bar/", line 1, in <module>
    import a
ImportError: No module named a
  • Issues #94: Packaging error with recursive naming new

Comments (7)

  1. Ian Bell

    Ok, the PR seems to fix the

    import CoolProp.Plots.Ph as Ph

    and it pulls in the necessary code from CoolProp. It is still not possible to include CoolProp as a package (step 2?), but I guess that is to be expected given your workaround.

    1. Thomas Kluyver author

      What error do you see now? When I add it back to packages, I get an error with matplotlib (it fails to find mpl-data), but if I put matplotlib in excludes, it seems to build OK.

  2. Anthony Tuininga repo owner

    Hmm, we may wish to do a recursion check instead of turning off the searching of all of the parent packages. That said, since Python 3 doesn't do this any longer and the emphasis is on absolute imports (and well defined relative imports) maybe we can use this workaround and suggest that anyone depending on the old behavior should get that changed? Thoughts?

  3. Thomas Kluyver author

    Unless I'm missing something, the old behaviour was simply erroneous: implicit relative imports on Python 2 don't search parent packages: they search in the current package, and then go to search sys.path like an absolute import. That's what my sample above in the PR description aims to demonstrate. As far as I know, if wants to import foo.a, it either has to do it absolutely (from foo import a) or with an explicit relative import (from .. import a).

    So I don't think anyone can have been relying on the old behaviour.