Firstly, it's always a good idea to install requirements into virtual environments, instead of system Python. It worth to note that starting from Python 3.3 the venv module was added that makes this process straightforward.
The error you're getting related to the process of handling modules in Django. Actually there is a difference between the result of the example when running in the default console and in Django shell. Consider this example:
# globally load the module, let's check what's inside.
>>> import django
>>> dir(django) # only the content from the __init__.py was imported.
['VERSION', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__',
'__name__', '__package__', '__path__', '__spec__', '__version__',
'get_version', 'setup', 'utils']
>>> from django import *
>>> print(django.apps)
>>> Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 'django' has no attribute 'apps'
>>> globals() # no Django submodules were loaded.
In the same time running the commands above in the Django shell:
>>> import django
>>> dir(django)
['VERSION', '__builtins__','__cached__','apps','setup','template',
'templatetags','urls','utils', 'views', ...]
>>> print(django.apps)
>>> <module 'django.apps' from .../django/apps/__init__.py>
>>> globals() # some of the Django submodules were loaded
When you make global Django import in the console, all the content from the __init__.py
will be loaded and there is no direct import of Django submodules inside. But Django shell on the first django
import makes availability of submodules as well.