I just saw someone ask "why do I have to prepend a dot to import a file in the same directory?"
That depends on whether the file with the import statement is in a package or not.
But, whether Python considers it to be in a package depends on how you imported (or ran) that file. You can't determine it from the file's content or the filesystem structure!
Check alt text (image description) for explanations of the examples.
Also, while in Python 2 packages had to have an init.py file (which is what made them a package), this is no longer true for Python 3. init.py files are completely optional.
An init.py file is being interpreted the first time some module from your package is imported. But it's also what allows you to import (from) a package instead of a module.
Many packages use this to provide easier access to things defined in sub-modules, which can be extra confusing for inexperienced devs.
@scy Even if they were optional, packaging tools still tend to expect them for auto-discovery. We've run into this a few times at work. I usually drop them except for in the root folder of a package.
@scy Several reasons. For libraries, I use it to control how things are imported by the user by exposing it there. Which means I can restructure the files behind it without changing the import path.
For applications, I use it as the entry point.
In both cases I often do some initialisation there, like set up logging, etc.
Damn, "mod_import.py" and "rel_mod_import.py" should have been called "pkg_import.py" and "rel_pkg_import.py" because they're importing the package itself (which is basically equivalent to importing the init.py) instead of a module.
I hope it's okay that I'm not redoing the screenshots and descriptions, I've spend way too much time on these two posts already.
Also, remember how I said whether you need to prepend a dot or not depends on whether you're in a package or not?
That's not entirely correct. It depends on your search path. If you run "python3 -m mypkg.abs_import", you're in the parent directory of mypkg, and Python modules inside of it won't be found without prefixing "mypkg." or doing a relative import.
Except … if you modify the search path, e.g. by prepending the "mypkg" directory to it, for example using the PYTHONPATH env variable.
@scy Yeah, I think this is the number one thing I've seen people who are relatively new to Python struggle with when they start to interact with a somewhat larger project. Imports really are super confusing...
(I personally ended up converging into two main import methodologies for simplicity... (1) is always use absolute from a single root directory and (2) use absolute, but mangle sys.path as needed at the top of the file before the imports. I generally use (1) for proper code and (2) for quick and dirty experiments... but it's not a good way to do Python at all)
@rfnix Since sys.path is global for the whole application, I'd be pretty furious if a random library I'm importing would mess with it just to fix their imports.
I don't think that's what you're suggesting, but I just wanted to make it extra clear that messing with sys.path in random files in your project is basically asking for trouble.
Add comment