Re: Import a module from a specific file path
Ben Finney : > 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__) More robustly: program_dir = os.path.dirname(os.path.realname(__file__)) Executables are often soft links. > 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? Your complaint is valid. Many modern programming languages (also java, guile, elisp etc) suffer from it. Java has alleviated the problem with jar files. So why don't C programmers complain about the problem? First, the #include directive does exactly what you are asking: it supports relative paths. Secondly, you can build executables statically. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Import a module from a specific file path
Chris Angelico writes: > So can you simply: > > $ python -m foo.fooprog > > ? (or 'python3', either way) So, that's a pretty awful user interface. (The file is named ‘fooprog’ because it's an executable, intended to be run directly at the command line.) That solution would be rather inferior to the program being able to import modules when invoked as the top-level program. Can you suggest solutions that allow invoking the program as ‘./fooprog’ to work? -- \ “In economics, hope and faith coexist with great scientific | `\ pretension and also a deep desire for respectability.” —John | _o__)Kenneth Galbraith, 1970-06-07 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Import a module from a specific file path (was: PyWart: "Python's import statement and the history of external dependencies")
Chris Angelico 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Import a module from a specific file path (was: PyWart: "Python's import statement and the history of external dependencies")
On Sat, Nov 22, 2014 at 11:37 AM, Ben Finney wrote: > 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. > > Allowing relative paths makes this portable, so long as the > application's relative tree structure is maintained. > > Maybe you can suggest a better portable method to do this today in > Python. Ah, didn't think of relative paths. Yes, I can see that'd be both more useful and less problematic. What you suggest looks very much like you're running something from a package, though. > * 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 So can you simply: $ python -m foo.fooprog ? (or 'python3', either way) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
