Import a module from a specific file path (was: PyWart: "Python's import statement and the history of external dependencies")

[Ben Finney]

Chris Angelico <rosuav at gmail.com> writes:

> In other words, what you want is:
>
> # today's method, import based on search path
> import sys
> # new explicit path method
> import '/usr/local/lib/python3.5/lib-dynload/math.cpython-35m.so'

I don't think I'd ever want to specify an absolute file path for the
module. But it would make my Python life immeasurably better if I could
specify *relative* file paths for importing a module.

    import '../foo/bar/beans.py' as beans

> Can you tell me, please, how this is going to work for *any* system
> other than the one it was built on?

Allowing relative paths makes this portable, so long as the
application's relative tree structure is maintained.

> There are a VERY VERY few cases where you really do want to import a
> module from a specific file path. For those situations, there are
> already techniques you can use. Why change the behaviour of import
> itself?

An example:

* I write a program, ‘fooprog’, using the hypothetical “import a module
  at a specified file path” feature::

    #! /usr/bin/python3

    import './bar/beans.py' as beans

    beans.do_stuff()

* The program ‘fooprog’ and the module ‘beans.py’ are in a sensible
  directory structure::

    foo-proj-1.0/
        foo/
            __init__.py
            fooprog
            bar/
                __init__.py
                beans.py
        tests/
            __init__.py
            test_fooprog.py
            test_bar.py

* Running the program ‘fooprog’ invokes Python (via its standard
  shebang), which invokes the file ‘fooprog’ as the ‘__main__’ module
  *with no package awareness*.

  Or, equivalently, ‘python foo/fooprog’ skips the shebang step.

* Regardless of package considerations, specifying ‘./bar/beans.py’
  locates the module ‘beans’ for import, just fine.

That example will work in the presence of this “import from a named file
location” feature.

But it will fail with the standard Python import feature today. How
would you expect this example to change so it will work with current
Python?

Solutions usually seem to entail contortions of cluttering the import
block by discovering the current path, and fussing around with
‘sys.path’, before finally doing the import::

    #! /usr/bin/python3

    import sys
    import os.path

    program_dir = os.path.dirname(__file__)
    parent_dir = os.path.dirname(program_dir)
    if not parent_dir in sys.path:
        sys.path.insert(1, parent_dir)

    import foo.bar.beans as beans

    beans.do_stuff()

Maybe you can suggest a better portable method to do this today in
Python.

Importantly, once you've come up with how to do it today in Python: Do
you really consider that superior to simply specifying a filesystem path
for a file containing the module?

-- 
 \        “I'd take the awe of understanding over the awe of ignorance |
  `\                                          any day.” —Douglas Adams |
_o__)                                                                  |
Ben Finney