I have a custom module that I am trying to read from a folder under a hierarchy:
> project-source
/tests
/provider
my_provider.py
settings_mock.py
__init__.py
I am trying to call, from my_provider.py
import tests.settings_mock as settings
Example from command line:
project-source> python tests/provider/my_provider.py
Error:
... ImportError: No module named settings_mock
I keep getting No module named settings_mock as error. I have already exported project_source path to PYTHONPATH. I have made tests into a package by creating a __init__.py file in its root, but no change in the error then.
I can print the settings_mock.py attributes when cd'ing project source
>>> import tests.settings_mock as settings
>>> print settings.storage_provider
correct storage provider value
Is anyone able to point out my mistake here? Thanks!
You only have one small mistake. To use subfolders, you need __init__.py, not init.py as you stated in the question. The difference is that __init__ is a builtin function of python, whereas init is not. Having this file in each subfolder tells the pyhon interpreter that the folder is a "package" that needs to be initialized.
UPDATED: It should be noted that python usually runs from the current directory that the script is located. If your executable main script is my_provider.py, then it's not going to know what to import, since the main script is located in a lower directory than the object it is trying to import. Think of it as a hierarchy. Scripts can only import things that are beneath them. Try separating out the executable from everything else in that file, if there are things that settings_mock needs to import.
Related
My folder structure in pycharm is as follows.
--python
--concepts
--common
--myds.py
--__init__.py
--data_structures
--test_ds.py
I have the following line in test_ds.py
from common import my_ds
I get the following error.
ImportError: No module named 'common'
I have added common to Settings --> Project Interpreter -> Interpreter Paths
and the folder shows up as library root.
Still why am I getting this error.
Try from ..common import my_ds. Also make sure that it has an __init__.py file in that directory (not required but it's good practice).
As for the .. they indicate that you're importing from the parent package to the one you're currently on.
You need to make your common folder into a python package in order to import it in python. I think you've tried to do it and created init file in your common folder but actually it must be __init__.py. Rename it like this and then your package will be visible to python.
Hope it helps!
I have some folders and .py files in the following structure:
parent/
__init__.py
test.ipynb
code/
__init__.py
common.py
subcode/
__init__.py
get_data.py
In the __init__ file under the parent folder, I have import code and in the one of code, I have import subcode. But when I tried import code.subcode, I got such an error:
ImportError: No module named 'code.subcode'; 'code' is not a package
But when I just import code, no error is thrown. However, when I call code.subcode, this error happens:
AttributeError: module 'code' has no attribute 'subcode'
I try all of those mentioned above in the test.ipynb, which is at the root of the directory.
Do you know what is the reason and how can I fix it? Thanks!
The problem is that you are importing another module named code that is installed on your system rather than your own module. You can verify this by checking the module file path in code.__file__ after you import code.
The first thing to do is change the name of your module to avoid namespace collisions with the other code package on your system. If your new package name doesn't collide with something else, you should now either successfully be importing it and have it behave as expected, or it fails to import entirely.
If it fails to import, it is most likely because your parent directory is not in your PYTHONPATH environment variable.
There can potentially also be other more technical reasons that a module is not recognized by the interpreter such as old definitions being cached (in which case restarting the interpreter is often enough. Possibly after deleting any precompiled versions of the module). Another problem I have seen ended up being that a module contained a bug that made the interpreter unable to parse it. I am sure there are other odd possibilities out there.
You're on Python 3. You need to perform relative imports explicitly:
from . import code
The code module you're currently getting is the standard library code module.
I have a module I have installed called lts_fits, and this is its path:
~/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/lts_fits
So it is clearly in the site packages folder. Within this folder, there is a python script:
lts_linefit.py
Yet when I have this line of code in my script:
from lts_fits import lts_linefit
I get this error:
ImportError: No module named lts_fits
How? It's clearly in there, and I have tried this same syntax with other random scripts and they import just fine. For instance, a file abc.py located in the folder ~/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/sympy imports just fine when I have the line from sympy import abc. What could be going wrong?
You need an __init__.py file in that directory (you do not have to put anything into the file, all you need to do is create it).
The easiest way to create said file is by using:
touch __init__.py
from within your lts_fits directory in your command line/terminal/console.
See this SO article: What is __init__.py for?
And the Python Documentation for packages.
I am creating module (with submodules). Lets call it lib. I am trying to make it work as following:
I am able to run it (there is lib.__main__). It uses lib.utils inside.
When executed part of its job is to load other file/module passed by user. Currently it does it by importlib.import_module( name ).
This loaded module also needs to use lib.utils.
I am having following choice:
In loaded module use import utils instead of import lib.utils. I find it somehow misleading and would like to aviod this.
Run module in any external way, even using file with only import lib.__main__ inside.
Only other thing I have tought of was doing sys.path.append(os.getcwd()). Not only it seems very dirty, but also makes log.utils module to load twice.
Is there anything that would allow me to execute lib.__main__, but require using import lib.utils in loaded module?
From the docs
If the script name refers to a directory or zipfile, the script name is added to the start of sys.path and the main.py file in that location is executed as the main module.
In your case, if you run python lib mymodule, lib is added to sys.path and __main__.py is executed. lib is not a package, its simply a directory in sys.path. __main__.py is not in a package and so package-relative imports don't work.
Since lib is in sys.path, its top level .py files can be imported directly and any subdirectories with __init__.py are importable packages. So, both __main__.py and mymodule could do import utils and get the same thing.
Now it gets confusing. Because you are sitting in lib's parent directory and because there is a lib.__init__.py, lib.utils is also valid. Its only that way because of your current directory (or maybe you added the directory to PYTHONPATH or something). So, you've got two different modules as far as python is concerned because you got there on two different paths.
The solution is to delete lib/__init__.py. lib shouldn't be package. Then you have the question of what to do with the modules like lib/utils.py. Normally, one would create a package directory and move the scripts there so that you get namespace encapsulation. Supposing you call that directory mypackages, then __main__.py and mymodule.py could both import mypackages.utils.
My project has root src folder created by pydev project wizard. Src folder is in the project's python path. Underneath that folder I have a package (folder with __init__.py) with two files: a.py and b.py. b.py is trying to import from a.py but I'm getting the error of unresolved import.
I was able to "fix" error by explicitly adding that subfolder to project's python path as additional src folder. Now I have two folders as src folders in pythonpath. What I don't understand is, why pydev is not able to resolve import since the package/folder I'm talking about is directly underneath root src folder which is in the python path. There are no python files in root src folder.
If I add __init__.py to root src folder, the issue is still there. I simply have to add subfolder to pythonpath in order to make error go away.
Am I doing something wrong ? This doesn't seem right.
EDIT:
I was wrong. My import syntax was incorrect. I should have done: from package.module import someting and not from module import something
It's hard to tell from your description, and actual code would help, but I suspect what you're looking for is a relative import.
If you have a file pkg/a.py that just does this:
import b
That will look for a top-level module somewhere on your sys.path named b.py.
But if you do this:
from . import b
Then it will look within (and only within) pkg for a file named b.py.
Alternatively, you could use an absolute import, the same way you would in a module outside the package, like one of these:
import pkg.b
from pkg import b
Your attempted workaround of adding pkg to sys.path is a very bad idea, for multiple reasons. For example, b and pkg.b will become different modules as far as Python is concerned, so the top-level code can end up getting run twice, you can end up with two separate copies of all of the globals (and even if you think "I'm not using globals", you probably as—classes and functions are globals, and you can easily end up with a situation where b.MyClass(3) != pkg.b.MyClass(3) unexpectedly, which is always fun to debug…), etc.
Adding an __init__.py to src is also a bad idea. That turns src into a package, meaning the proper qualified name for b is now src.pkg.b, rather than pkg.b, but there's no way to import it under the proper name (unless the parent directory of src happens to be on sys.path as well as src… in which case you have the exact same problem as the above paragraph).
See PEP 328 for more details, and the tutorial section on Packages for a simpler overview.