It is easier in Python 3 than it was. I wrote this and it worked on the first try, although I have some experience with it.

The dynamic module:

    » cat sub/test_module.py
    def hello(name):

        print(f'Hello {name}')

The main script:

    » cat test_script.py 
    from importlib import import_module

    full_module_path = 'sub.test_module'  # no ".py"
    module = import_module(full_module_path)

    # optional, if you want to use across the project:
    import sys
    sys.modules[full_module_path] = module
    print(sys.modules[full_module_path])
    # end optional

    # try it:
    module.hello('there!')

To run it:

    » python3 test_script.py
    <module 'sub.test_module' from '/home/foo/sub/test_module.py'>
    Hello there!

Stack overflow has its uses. But you shouldn't rely on it if things have changed, a lot of their advice is outdated and written by non-experts. The importlib module docs explain this concisely.

https://docs.python.org/3/library/importlib.html#importlib.i...

In general, I don't see the intrinsic complexity being reduced much more than this:

    from importlib import import_module

    module = import_module('sub.test_module')

Nice idea, unfortunately it will break all static tooling. IDEs, static type checker, linters, etc.

I used to work at a company where they had a custom import system and it was a nightmare.

Looks like people thought "." refers to the filesystem CWD instead of the current package. Python never made shell constructs that central. Admittedly, it never occurred to me to confuse these two, and so haven't had any of the problems any of those folks mention.

And you need (maybe used to?) an __init__.py file in each package.

But once you know that, it's straightforward, no? Certainly not, "only a few people in the world know this..." level. Don't think I'm some kinda level-10 genius here.

> And there's a foo/__init__.py file it gets executed merely from path traversal.

Yes, and it needs to—to find the variables there, which may/not be other packages.

> how Django's settings work

Right. Django is great and popular, and so I think many folks don't realize how downright clunky it is in a number of places. Many parts of it are over-engineered like this one. It has improved over time but some things are set in stone due to history. I'd like their settings redesigned myself.

> __init__.py to do the things they need, like retrieve secrets from AWS

No, no, no, no... NO! ;-)

Imports should only create variables, define functions, and/or alias a package. They should never, ever run lengthy computations or access the network. That's basic software design 101, unfortunately not taught everywhere.

I don't see this one as a clear flaw of Python. "Dumb" coding can happen anywhere. I suppose it could prohibit this kind of stuff, but that might prohibit other cool things that might be reasonable in limited situations. It is a "consenting adults" design, with those trade offs.