I ran into something similar and the answer from OP about namespace collision is what finally clued me in.

I was using the same name for both a sub-package (directory) and a module (file) within it.

For example I had this:

/opt/mylib/myapi
/opt/mylib/myapi/__init__.py
/opt/mylib/myapi/myapi_creds.py        # gitignored file for user/pass
/opt/mylib/myapi/myapi.py              # base module, load creds and connect
/opt/mylib/myapi/myapi_dostuff.py      # call myapi.py and do work

The script 'myapi.py' imports credentials from myapi_creds.py via this statement:

from myapi.myapi_creds import my_user, my_pass

Testing the module 'myapi.py' resulted in this error:

$ ./myapi.py
Traceback (most recent call last):
  File "./myapi.py", line 12, in <module>
    from myapi.myapi_creds import my_user, my_pass
  File "/opt/mylib/myapi/myapi.py", line 12, in <module>
    from myapi.myapi_creds import my_user, my_pass
ModuleNotFoundError: No module named 'myapi.myapi_creds'; 'myapi' is not a package

The solution was to rename myapi.py to myapi_base.py so it's name does not collide with the sub-package name.

Foreword

I'm developing a project which in fact is a Python package that can be installed through pip, but it also exposes a command line interface. I don't have problems running my project after installing it with pip install ., but hey, who does this every time after changing something in one of the project files? I needed to run the whole thing through simple python mypackage/main.py.

/my-project
    - README.md
    - setup.py
    /mypackage
      - __init__.py
      - main.py
      - common.py

The different faces of the same problem

I tried importing a few functions in main.py from my common.py module. I tried different configurations that gave different errors, and I want to share with you with my observations and leave a quick note for future me as well.

Relative import

The first what I tried was a relative import:

from .common import my_func

I ran my application with simple: python mypackage/main.py. Unfortunately this gave the following error:

ModuleNotFoundError: No module named '__main__.common'; '__main__' is not a package

The cause of this problem is that the main.py was executed directly by python command, thus becoming the main module named __main__. If we connect this information with the relative import we used, we get what we have in the error message: __main__.common. This is explained in the Python documentation:

Note that relative imports are based on the name of the current module. Since the name of the main module is always __main__, modules intended for use as the main module of a Python application must always use absolute imports.

When I installed my package with pip install . and then ran it, it worked perfectly fine. I was also able to import mypackage.main module in a Python console. So it looks like there's a problem only with running it directly.

Absolute import

Let's follow the advise from the documentation and change the import statement to something different:

from common import my_func

If we now try to run this as before: python mypackage/main.py, then it works as expected! But, there's a caveat when you, like me, develop something that need to work as a standalone command line tool after installing it with pip. I installed my package with pip install . and then tried to run it...

ModuleNotFoundError: No module named 'common'

What's worse, when I opened a Python console, and tried to import the main module manually (import mypackage.main), then I got the same error as above. The reason for that is simple: common is no longer a relative import, so Python tries to find it in installed packages. We don't have such package, that's why it fails.

The solution with an absolute import works well only when you create a typical Python app that is executed with a python command.

Import with a package name

There is also a third possibility to import the common module:

from mypackage.common import my_func

This is not very different from the relative import approach, as long as we do it from the context of mypackage. And again, trying to run this with python mypackage/main.py ends similar:

ModuleNotFoundError: No module named 'mypackage'

How irritating that could be, the interpreter is right, you don't have such package installed.

The solution

For simple Python apps

Just use absolute imports (without the dot), and everything will be fine.

For installable Python apps in development

Use relative imports, or imports with a package name on the beginning, because you need them like this when your app is installed. When it comes to running such module in development, Python can be executed with the -m option:

-m mod : run library module as a script (terminates option list)

So instead of python mypackage/main.py, do it like this: python -m mypackage.main.