5 ms·

Earnest question: why are you all trying to use relative imports? What problem is that solving for you? I've never even bothered to try it out because it seems

Earnest question: why are you all trying to use relative imports? What problem is that solving for you? I've never even bothered to try it out because it seems potentially problematic in the way all relative references can be, e.g., relative file paths.

scaryclam 5y ago
So much this. There's no good reason to use relative imports. They're less readable, more dangerous and don't solve a single problem.
- zarzavat 5y ago
  In JS land everything is a relative import. It's nice because you can move a whole directory of code from one project to another (or around in the same project) and it still works because all the imports pointing to other files inside that directory were relative, you only have to fix imports that go outside the directory. Also the way that JS imports are just relative paths is very nice because it means that the imports are statically determinable, your editor can understand them and fix them automatically and you can trust that refactoring. Python has turing complete imports because there's so much dynamic messing about with sys.path that goes on in Python due to inadequacies of the import system.
  - noptd 5y ago
    Given most editors handle absolute imports as good as if not better than relative imports, I don't see any real benefit to using the latter.
    - true_religion 5y ago
      It stops some circular imports if you use relative imports.
      - np_tedious 5y ago
        I'd rather suffer the late import with absolutes than wrestle with relative imports
  - BossingAround 5y ago
    > It's nice because you can move a whole directory of code from one project to another (or around in the same project) and it still works Yes, just like absolute imports... > relative paths is very nice because it means that the imports are statically determinable, your editor can understand them and fix them automatically and you can trust that refactoring 1) Just like absolute imports? 2) I absolutely contest that relative imports are easier for an IDE to refactor. I've never had VSCode hang while refactoring a Java package; I've had VSCode hang while refactoring "create-react-app" app...
    - zarzavat 5y ago
      In Python you can do (and people do do) this import a.b.c sys.path.insert(0, 'some/other/path') import x.y.z Or env PYTHONPATH="foo/bar:$PYTHONPATH" python ... There is no way in general for Python tooling to figure out where an import points. All it can do is guess. It's a very regrettable situation. Yes in Java it's fine because Java has a build stage. So tooling can figure out where imports point to from your static configuration. However from the tool's perspective there is nothing better than a relative path. Relative paths require no messing about with configuration files at all to resolve. It's just a path to another file or directory on disk. When a tool sees import c from "./a/b/c" It can resolve it immediately. So what is the advantage of absolute imports really? If import lines are mainly written and maintained by tooling then shouldn't we pick the representation that is easiest for the tooling? Then we can have more and better tools and the tools will be more reliable. And it turns out that, relative paths are easy for humans to understand too. The same configuration-free resolution algorithm also works in your head when you are reading code! At least when the language doesn't overcomplicate them too much (JS is guilty of this to a certain extent, although nowhere as bad as Python)
- hermitdev 5y ago
  IIRC, it was done for security, to avoid inadvertently picking up a library from an unexpected place. For instance, drop a file named test.py in the same directory as your python 2 script and have "fun" figuring out what went wrong.
rocqua 5y ago
People have a script run with python, and want to use code in other files. This is not supported in python. For reasons beyond my understanding, you are supposed to put the script with python, or with the shebang, in a different directory. Alternatively, you can always use `python -m` to run your code.
- blakesley 5y ago
  > People have a script run with python, and want to use code in other files. This is not supported in python. Come again? This is what "import" does, obviously. This is not a clear explanation of your problem.
  - rocqua 5y ago
    I missed one detail. The files and the script are in the same folder. I say script here because the apparent intention is that scripts and modules are separate. That is why it's not easy to import functions from a file in the same directory as a script. This restriction is very unexpected. And it is not borne out well by the fact that it is not obvious this distinction exists.
    - formerly_proven 5y ago
      When you run a script, the directory containing it is on the path. You can just write "from somefile import something". What you can't do is "from .somefile import something" because it is not a package. When you run a module, the root package containing it is on the path by definition and imports work.
      - rocqua 5y ago
        I didn't know that. Does that still work if you call the script from a different directory (so `python bar/foo.py`)? Imma guess it doesn't work with symlinked scripts. But I don't think it should without doing an install, in which case a module does make sense.
eesmith 5y ago
While I rarely need it, I like being able to vendor a package by dropping it into a project subdirectory. If the package uses absolute paths then I would need to tweak all the imports for the new absolute path.
Galanwe 5y ago
I do use them quite often without much issue, not sure why some people are struggling with it. Say you have a main package "mylib" with a subpackage "mylib.utils". Typically I like to see "mylib.utils" imports as being in one of (roughly) 4 categories: - standard imports, that I would put first in the file (e.g. "import logging") - external imports, that I would put second in the file (e.g. "import requests") - library local imports, bits and pieces from the "mylib" package that you want to reuse in "mylib.utils", but are external to the current package (e.g. "from mylib.email import client") - and package local imports, which I see as implementation details of the current subpackage, and should be agnostic from the overall architecture of "mylib" (e.g. "from .helpers import help_function") The last category are modules that only make sense from within "mylib.utils", should relocate with it even if it is renamed or moved elsewhere, and shouldn't require a change whatever the structure of "mylib" becomes, which is why I would use "mylib.utils" relative imports in there.

scaryclam 5y ago

So much this. There's no good reason to use relative imports. They're less readable, more dangerous and don't solve a single problem.

zarzavat 5y ago
In JS land everything is a relative import. It's nice because you can move a whole directory of code from one project to another (or around in the same project) and it still works because all the imports pointing to other files inside that directory were relative, you only have to fix imports that go outside the directory. Also the way that JS imports are just relative paths is very nice because it means that the imports are statically determinable, your editor can understand them and fix them automatically and you can trust that refactoring. Python has turing complete imports because there's so much dynamic messing about with sys.path that goes on in Python due to inadequacies of the import system.
- noptd 5y ago
  Given most editors handle absolute imports as good as if not better than relative imports, I don't see any real benefit to using the latter.
  - true_religion 5y ago
    It stops some circular imports if you use relative imports.
    - np_tedious 5y ago
      I'd rather suffer the late import with absolutes than wrestle with relative imports
- BossingAround 5y ago
  > It's nice because you can move a whole directory of code from one project to another (or around in the same project) and it still works Yes, just like absolute imports... > relative paths is very nice because it means that the imports are statically determinable, your editor can understand them and fix them automatically and you can trust that refactoring 1) Just like absolute imports? 2) I absolutely contest that relative imports are easier for an IDE to refactor. I've never had VSCode hang while refactoring a Java package; I've had VSCode hang while refactoring "create-react-app" app...
  - zarzavat 5y ago
    In Python you can do (and people do do) this import a.b.c sys.path.insert(0, 'some/other/path') import x.y.z Or env PYTHONPATH="foo/bar:$PYTHONPATH" python ... There is no way in general for Python tooling to figure out where an import points. All it can do is guess. It's a very regrettable situation. Yes in Java it's fine because Java has a build stage. So tooling can figure out where imports point to from your static configuration. However from the tool's perspective there is nothing better than a relative path. Relative paths require no messing about with configuration files at all to resolve. It's just a path to another file or directory on disk. When a tool sees import c from "./a/b/c" It can resolve it immediately. So what is the advantage of absolute imports really? If import lines are mainly written and maintained by tooling then shouldn't we pick the representation that is easiest for the tooling? Then we can have more and better tools and the tools will be more reliable. And it turns out that, relative paths are easy for humans to understand too. The same configuration-free resolution algorithm also works in your head when you are reading code! At least when the language doesn't overcomplicate them too much (JS is guilty of this to a certain extent, although nowhere as bad as Python)
hermitdev 5y ago
IIRC, it was done for security, to avoid inadvertently picking up a library from an unexpected place. For instance, drop a file named test.py in the same directory as your python 2 script and have "fun" figuring out what went wrong.

rocqua 5y ago

People have a script run with python, and want to use code in other files. This is not supported in python. For reasons beyond my understanding, you are supposed to put the script with python, or with the shebang, in a different directory. Alternatively, you can always use `python -m` to run your code.

blakesley 5y ago
> People have a script run with python, and want to use code in other files. This is not supported in python. Come again? This is what "import" does, obviously. This is not a clear explanation of your problem.
- rocqua 5y ago
  I missed one detail. The files and the script are in the same folder. I say script here because the apparent intention is that scripts and modules are separate. That is why it's not easy to import functions from a file in the same directory as a script. This restriction is very unexpected. And it is not borne out well by the fact that it is not obvious this distinction exists.
  - formerly_proven 5y ago
    When you run a script, the directory containing it is on the path. You can just write "from somefile import something". What you can't do is "from .somefile import something" because it is not a package. When you run a module, the root package containing it is on the path by definition and imports work.
    - rocqua 5y ago
      I didn't know that. Does that still work if you call the script from a different directory (so `python bar/foo.py`)? Imma guess it doesn't work with symlinked scripts. But I don't think it should without doing an install, in which case a module does make sense.

eesmith 5y ago

While I rarely need it, I like being able to vendor a package by dropping it into a project subdirectory. If the package uses absolute paths then I would need to tweak all the imports for the new absolute path.

Galanwe 5y ago

I do use them quite often without much issue, not sure why some people are struggling with it. Say you have a main package "mylib" with a subpackage "mylib.utils". Typically I like to see "mylib.utils" imports as being in one of (roughly) 4 categories: - standard imports, that I would put first in the file (e.g. "import logging") - external imports, that I would put second in the file (e.g. "import requests") - library local imports, bits and pieces from the "mylib" package that you want to reuse in "mylib.utils", but are external to the current package (e.g. "from mylib.email import client") - and package local imports, which I see as implementation details of the current subpackage, and should be agnostic from the overall architecture of "mylib" (e.g. "from .helpers import help_function") The last category are modules that only make sense from within "mylib.utils", should relocate with it even if it is renamed or moved elsewhere, and shouldn't require a change whatever the structure of "mylib" becomes, which is why I would use "mylib.utils" relative imports in there.