Алексей Елецкий

Разбивать настройки по разныим *.py файлам для разных окружений не очень удобно.

Удобнее иметь один settings.py, который импортирует настройки из какого-нибудь общераспространённого формата (json, ini, etc). В этом плане django-environ может быть удобным, но не обязательным решением.

держать его вне системы контроля версий

Делать это не нужно. Хотя можно держать конфиги вне репозитория приложения — в отдельном репозитории со скриптами деплоя (так как не все люди, имеющие доступ к исходникам, должны иметь доступ к параметрам деплоя, и наоборот).

Держать настройки непосредственно в *.py файлах неудобно по тому, что в них, кроме прямых указаний параметров, ещё может быть разный код для их подготовки (всё-таки, это обычный код на Python). При доставке кода на сервера такие конфиги так или иначе генерируются. В итоге усложняется разработка - появляется необходимость править код и в *.py файле, который использует разработчик и в шаблоне этого же файла, который будет использоваться для генерации конфига на сервере. Такой подход — прямой путь к багам.

Напишите декоратор, который принимает список моделей, а внутри оборачивает функцию в @receiver для каждой из них.

Примерно так.

def my_receiver(models):

    def decorator(func):
        for model in models:
            func = receiver(pre_save, sender=model)(func)
        return func

    return decorator

@my_receiver(models=[Model1, Model2, Model3])
def recalculate_data(instance, **kwargs):
    pass