Maybe you’ve been lucky so far and never experienced the flaky, breaky side of internal importing in Python – for example, mysterious If you want your internal imports to work reliably, the following rules will guarantee success. Other approaches may also work, at least some of the time, but the rules presented below will always work. Following these rules will also make it possible to run modules as scripts1<\/a><\/sup> no matter where they occur in the code structure. This can be especially useful during development.<\/p>\n\n\n\n Use absolute importing everywhere in your code package, not just where you think internal importing is broken<\/p>\n\n\n\n Python has both relative and absolute importing. Relative importing is relative to the file doing the importing and uses dots e.g. one for the existing folder, two for the parent folder, three for grandparent etc. How many dots you need, and what your import looks like, depends on where you are in the folder structure. Absolute importing starts from an anchor point which is the same wherever the file doing the importing is.<\/p>\n\n\n\n DO:<\/p>\n\n\n\n DON’T:<\/p>\n\n\n\n Anchor absolute imports from the code package folder. E.g. if we have a module in a location like: assuming the code package folder was the rightmost charm folder.<\/p>\n\n\n\n It is common to use the same name for the surrounding folder as the code package folder but we don’t have to and the following example might make the situation more clear. If we have a module in a location like: DO:<\/p>\n\n\n\n DON’T:<\/p>\n\n\n\n Don’t import folders – instead import modules or attributes of modules.<\/p>\n\n\n\n DO:<\/p>\n\n\n\n DON’T:<\/p>\n\n\n\n One doesn’t simply run code. Code is always executed with a particular context, often implicitly. Use one of the ways that works i.e.<\/p>\n\n\n\n Either use or<\/p>\n\n\n\n ensure your IDE has the surrounding folder, the folder surrounding the code_package, in its python path ( You can always run the following one-liner before the problem to see what is in your python path:<\/p>\n\n\n\n I have seen mysterious internal importing problems impact numerous Python developers. The Python import system is very flexible and extensible but it is far from simple. Flaky, breaky internal importing is definitely not only a problem for beginners.<\/p>\n\n\n\n Confusion is increased by such factors as:<\/p>\n\n\n\n You don’t necessarily have to follow the “rules” above to get your internal imports working, but why take the risk? Follow the rules and then you can turn your precious attention to other programming issues. Here they are again:<\/p>\n\n\n\n Flaky, Breaky Internal Importing Maybe you’ve been lucky so far and never experienced the flaky, breaky side of internal importing in Python – for example, mysterious ModuleNotFound exceptions. But if internal importing has been a problem, typically when code is … Continue reading ModuleNotFound<\/code> exceptions. But if internal importing has been a problem, typically when code is imported from a multi-folder code base, it is good to know there is at least one guaranteed solution.<\/p>\n\n\n\nTear-Free Rules2<\/a><\/sup><\/h2>\n\n\n\n
\n
#1 Be Absolute<\/h3>\n\n\n\n
import charm.tables.freq\nimport charm.conf\nimport charm.utils.stats.parametric.ttest<\/code><\/pre>\n\n\n\nfrom ..stats.parametric import ttest\n\nfrom . import ttest ## importing same thing but doing it from another module<\/code><\/pre>\n\n\n\n#2 Anchor Well<\/h3>\n\n\n\n
\/home\/pygrant\/projects\/charm\/charm\/tables\/freq.py<\/code> we would import it like:<\/p>\n\n\n\nimport charm.tables.freq<\/code><\/pre>\n\n\n\n\/home\/pygrant\/projects\/charm_project\/charm\/tables\/freq.py<\/code> we would import it from charm<\/code> (the code package folder) not charm_project<\/code> (the surrounding folder).<\/p>\n\n\n\nimport charm.tables.freq<\/code><\/pre>\n\n\n\nimport tables.freq ## <===== missing the anchor i.e. the code package folder<\/code><\/pre>\n\n\n\n#3 Folder Imports Bad!<\/h3>\n\n\n\n
import charm.tables.freq<\/code><\/pre>\n\n\n\nimport charm.tables ## <== a folder - so you might be importing\n ## the __init__.py under that folder if there is one\ntables.freq.get_html()<\/code><\/pre>\n\n\n\n#4 Don’t Just “Run” Code<\/h3>\n\n\n\n
\n
sys.path<\/code>, so Python can find your modules to actually import their contents<\/li>\n\n\n\n-m<\/code> option<\/p>\n\n\n\npython -m code_package.folder.folder.script<\/code> <– without .py<\/code> extension<\/p>\n\n\n\nsys.path<\/code>) (possibly defined in quirky, possibly unintuitive IDE-specific ways)<\/p>\n\n\n\nimport sys; print('\\n'.join(sys.path))<\/code><\/pre>\n\n\n\nFinal Comments<\/h2>\n\n\n\n
\n
In .vscode\/settings.json<\/code> add:\"terminal.integrated.env.windows\": {
\"PYTHONPATH\": \"${workspaceFolder}\"
}<\/code>
where ${workspaceFolder}<\/code> points “to the surrounding folder”, either relative to the workspace folder using the ${...}<\/code> syntax, or as an absolute path. Also put this in .env<\/code> as an absolute path to the surrounding folder:PYTHONPATH=<path-to-surrounding folder><\/code>
Simple right? \ud83d\ude09
PyCharm seems to require using the correct content root and allowing the Content Roots to be added to the PYTHONPATH. If the project is created off the surrounding folder this is probably the default behaviour but if this doesn’t happen it is not obvious how to fix the problem.<\/li>\n<\/ul>\n\n\n\n\n
rather than just defining something without running it (e.g. defining a function or a class). \u21a9\ufe0e<\/a><\/li>