Датасеты по позам есть уже, на счет танцев не уверен.

да мне слегка sophisticated

В модуле logging предусмотрен немного необычный способ форматирования строки без форматирования.

logging.info('Message %s %s', arg1, arg2)

На самом деле, если вы его не используете то вы делаете неправильно!⚠️

Если вам требуется указать в строке сообщения какой-либо аргумент то обычно это делается форматированием строки

logging.info('New value is %s' % value)

Или любой другой доступный нам способ

logging.info(f'New value is {value}')
logging.info(f'{value=}')

Кажется, всё логично, все так делают. Но нет, это ошибка! 😫

Функция записи сообщения должна быть очень быстрой. Да, она в любом случае занимает время, но чем меньше тем лучше. И особенно, когда это сообщение не проходит по фильтру уровня логирования.
Например, у меня установлен уровень WARNING и выполняется вот такой вызов

logging.debug(f'Current user: {user}')

Что произойдет?
Сообщение не попадает под установленный уровень логирования и будет проигнорировано. Это обрабатывается сразу же первой командой в вызываемой функции debug. Но при этом форматирование строки всё равно произойдёт!
И проблема не в самом форматировании, которое достаточно быстрое (даже при складывании строк через "+"), а в тех возможных действиях, которые придется вызвать для преобразования объекта user в строку.

Возможно, там будет запрос в БД, разбор больших массивов данных или еще что-то не очень быстрое (или не очень умное🤪).
Нам всё это придётся посчитать чтобы потом.....ничего с этим не сделать.

Поэтому правильно писать так:

logging.debug('Current user: %s', user)

Мы просто передаём подготовленную неформатированную строку и аргументы для форматирования, это не требует вычислений. Но само форматирование и сопутствующие вызовы произойдут только в случае когда это действительно потребуется, то есть уровень сообщения попадает под условия настройки текущего логгера.

#libs #tricks

есть нейронки, которые распознают позы, возможно есть и те, что действие распознают, но это уже видимо серия поз, возможно нужно будет создать свой датасет и разметить

Мое решение было такое, переименовал файл с celery.py на celery_app.py; make it simple

import .celery?

какой канал посоветуешь?

+

+

+

там условие еще, кто хорошо знает русский язык и умеет читать требования ;)

+

+

Во даёте, там же написано, в ЛС писать)

.

В тебе умирает сммщица 🤣

В целом идея правильная, но оправдывать это производительностью, пожалуй, неверно, и вот почему:

1) запись в файл в любом случае займёт кучу времени, гораздо большую чем операция форматирования строки
2) если при обращении к атрибуту класса происходит какая-то медленная операция, то запись "правильным" способом не спасёт. Разве что в случае, если метод str объекта вызывает медленную операцию (но тогда logging тут ни при чём)

Я думаю, что главные причины, почему желательно передавать это в виде переменных в другом:
1) Интернационализация (порядок слов в разных языках бывает разным)
2) Может быть детальное представление данных объекта, чтобы при просмотре логов, можно было посмотреть его структуру.

во-первых, там не про запись в файл, во-вторых, суть в том, что при генерации строки не делать лишних действий если эта строка не будет выводиться и там как раз акцент, что пробелма не в форматировании строки, а вычислении переменных, допустим чтение из базы данных

я во многих примерах встречал форматирование как описано в этой статье, но сам чаще использую fstring, теепрь вот думаю, что надо пересмотреть