4 ms·

> 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 absolu

> 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)

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)