Ask HN: Why Python relative import is so fundamentally broken?

it was always meant as an helper: #a/__init__.py from .suba import A from .subb import B #script.py from a import A, B

If you want to import local files you have to edit the module path to include the current directory.

Python is born as a scripting language. Current directory is very important for this reason. You enter a folder and you launch your script with the current python version. Long before virtualenvs and pip itself.

Its not broken? Just like with everything, you have to understand semantics.

If you are writing anything more than a single file, a.k.a a module that has directories and subdirectories, which you will import in another place, you are supposed to put everything into a package format and install it with pip install -e ./

Then, within the module are free to use the absolute imports starting with the module name, or relative ones, and it all works like a charm. The import system is designed around this.

Alternatively, you can modify the PYTHONPATH env variable, or modify sys.path dynamically, to append to paths and import directly.

If i say because python was poorly designed language in the first place (and still is pretty mediocre by 2023 devx standards) - people will downvote, because they got attached to the naked king too much.

> Seems that relative import is implemented as relative to where the python.exe executed instead of the place where the file is.

That's not true, why do you think that? Relative Imports are anoying BS, but by default they do work based on the package-hierachy of the executed file, at least with normal Python. It could be there is something in your setup or handling of imports which changes this behaviour, as changing the import-mechnism is possible in python.

> So the nature is depending on where you run the doctest or where you put your jupyter notebook, all imports inside the project will break!

Maybe in those cases, the executed file is not what you think it is? So your top-level package is not located where your test is. Do you execute the test-file directly (python3 test.py), or do you use some starter-script (py.test test.py)?