Arquitectura de complementos - Administrador de complementos frente a la inspección desde la importación de complementos *

Actualmente estoy escribiendo una aplicación que le permite al usuario extenderla a través de una arquitectura de tipo 'complemento'. Pueden escribir clases de python adicionales basadas en un objeto BaseClass que proporciono, y estas se cargan contra varias señales de aplicación. El número exacto y los nombres de las clases cargadas como complementos se desconocen antes de que se inicie la aplicación, pero solo se cargan una vez en el inicio.

Durante mi investigación sobre la mejor manera de abordar esto, he encontrado dos soluciones comunes.

Opción 1: ruede la suya con imp, pkgutil, etc.
Ver por ejemplo,esta respuesta oéste.

Opción 2 - Usar una biblioteca de administrador de complementos
Escogiendo al azar una pareja

straight.pluginyapsyEste enfoque

Mi pregunta es, con la condición de que la aplicación debe reiniciarse para cargar nuevos complementos, ¿hay algún beneficio de los métodos anteriores sobre algo inspirado enesta respuesta SO yéste como:

import inspect
import sys
import my_plugins

def predicate(c):
    # filter to classes
    return inspect.isclass(c)

def load_plugins():
    for name, obj in inspect.getmembers(sys.modules['my_plugins'], predicate):
        obj.register_signals()

¿Hay algún inconveniente en este enfoque en comparación con los anteriores? (aparte de todos los complementos deben estar en el mismo archivo) ¡Gracias!

EDITAR
Los comentarios solicitan más información ... lo único adicional que puedo agregar es que los complementos usan elintermitente Biblioteca para proporcionar señales a las que se suscriben. Cada complemento puede suscribirse a diferentes señales de diferentes tipos y, por lo tanto, debe tener su propio método de "registro" específico.

Respuestas a la pregunta(3)

Su respuesta a la pregunta