Question

I just started experimenting with a new technique I name (for the moment at least) “module duck typing”.

Example:

Main Module

import somepackage.req  ## module required by all others
import abc
import Xyz

Module abc

__all__=[]

def getBus():
    """ Locates the `req` for this application """
    for mod_name in sys.modules:
        if mod_name.find("req") > 0:
            return sys.modules[mod_name].__dict__["Bus"]
    raise RuntimeError("cannot find `req` module")

Bus=getBus()

In module abc I do not need to explicitly import req: it could be anywhere in the package hierarchy. Of course this requires some discipline…

With this technique, it is easy to relocate packages within the hierarchy.

Are there pitfalls awaiting me? e.g. moving to Python 3K

Updated: after some more testing, I decided to go back to inserting package dependencies directly in sys.path.

Answer 1

There might be all kinds of modules imported that contain “req” and you don’t know if it’s the module you are actually looking for:

>>> import urllib.request
>>> import tst
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "tst.py", line 12, in <module>
    Bus=getBus()
  File "tst.py", line 9, in getBus
    return sys.modules[mod_name].__dict__["Bus"]
KeyError: 'Bus'

The whole point of packages is that there are namespaces for module hierarchies. Looking up module names “from any package” just causes your code to break randomly if the user happens to import some library that happens to contain a module with a conflicting name.