Roman Kitaev

Т.к. ты ничего не ответил на мой вопрос про списки, стало быть, они не нужны. Тогда ответ такой:

def merge_dicts(d1, d2):
    result = d1.copy()
    
    for key, value in d2.items():
        if key in result and isinstance(value, dict) and isinstance(result[key], dict):
            result[key] = merge_dicts(result[key], value)
        else:
            result[key] = value
    return result

Бесполезный res, который можно заменить счётчиком

go обычно прячут за реверс-прокси (например, nginx). У nginx есть access log, поэтому на стороне сервиса избыточно это логировать.

А зачем это нужно — для расследований инцидентов, для составления статистики по логам. Например, количество запросов в день/час/минуту/секунду — смотреть всплески нагрузки, распределение по кодам ответа, популярные урлы, айпишники юзеров чтобы видеть ботнеты из Китая. Куча применений.

Можно

https://redis.io/topics/notifications

По сути, всё, кроме pytest и unittest мертво. А django test runner — это и есть unittest. Поэтому, выбирай между pytest и unittest. pytest имеет кучу плюшек по сравнению с unittest.

select_related, prefetch_related, django-mptt

1. Смотришь в БД на последний объект, созданный этим пользователем. Он должен быть создан не раньше, чем X часов назад, либо не существует ни одного объекта — Model.objects.filter(user_id=...).latest('created_at')
2. Смотришь в БД на объекты, которые созданы сегодня. Их должно быть меньше Y — Model.objects.filter(user_id=..., created_at__date=date.today()).count()

Если оба условия выполняются — даёшь создать объект. В чём сложность?

https://docs.python.org/3/library/collections.html...

Django ORM. У него есть fluent interface. Повангую, этот пример делает какие-то агрегационные действия (в metrics), группирует их по sale__category__name и сортирует по total_sales в порядке убывания, где total_sales — какая-то агрегационная функция, которой ты не написал (скорее всего Sum чего-то)

Парсинг — это чуть ли не первое в списке того, ради чего стоит использовать асинхронность. Чем больше IO операций — тем больше преимуществ у асинхронного подхода перед тредпулом. Если при парсинге необходимо выполнять CPU-bound операции (разбор XML/HTML и прочее) — это выносится в тредпул (для питона — процеспул) и через асинхронные биндинги (например, в питоне это run_in_executor) отдаётся на откуп туда, главный же поток при этом не блокируется.

Пример на коленке, который парсит граф ссылок с википедии, с процесспулом, lxml и прочими ништяками: тык