Алан Гибизов

Вот предлагаю поиграться с этим кодом. Накидал что первое в голову пришло, но без всяких индексов i j в которых можно легко запутаться

s = 'Вот какая-то длинная строка, ниже я установил лимит. Строка разбивается на подстроки по длине не превосходящей этот лимит.'
limit = 20


def foo(s, limit):
    rows=[]
    current_row=[]
    length=0
    lst = s.split()
    for word in lst:
        if limit <= (length + len(word) + 1):
            rows.append(' '.join(current_row))
            current_row=[word]
            length = len(word)+1
        else:
            length += len(word)+1
            current_row.append(word)
    rows.append(' '.join(current_row))

    return('\n'.join(rows))

print(foo(s, limit))

Для коротких списков есть тип данных: ENUM.
Поддерживается, например, в MySQL, Postgres.

Идеально подойдёт для:

1. Статусы заказа (открыт/выпущен/закрыт и т. п.)
   
2. Статусы сборки заказа (ожидает сборки, сборка начата, сборка проверена, сборка завершена)
   
3. Формула оплаты заказа (тут много вариантов)
   
4. Фонд оплаты (собственные средства, федеральный бюджет, территориальный и т. п.))
   
5. Внутренний клиент (одно из возможных внутренних ООО)
   
6. Ответственный сотрудник
   
7. Территориальный сектор
   
8. Направление
   

тут несколько подходов, я трогал каждый из них и все они имеют право на существования
1. оставь как есть, я рекомендую, пусть будет 100500 таблиц справочников (если проблем с именами нет ну и отлично), fk-индексы все это свяжут а инструменты анализа базы данных помогут с этим работать (автоматические query builder с мышевозекательным интерфейсом) и база будет сама следить за тем что идентификаторы справочников не противоречивы
недостатков я не могу придумать, кроме может быть сильно разросшейся структуры, когда то давно я слышал что некоторые базы данных при увеличении количества таблиц начинают хуже работать но как я понимаю это если их будет десятки тысяч а не десятки и сотни.. может быть резервное копирование такой базы или ее репликация будет проходить чуть медленнее или еще хуже, организационно репликация может быть настроена на не рассылку ddl модификаций, в этом случае создание нового справочника будет задавать работу еще и админам, что нежелательно.

2. противоположный, использование одной таблицы key-value для нескольких разнородных справочников (id, value, table_name), в 99% случаев можно использовать один сиквенс (одну последовательность идентификаторов), вам же не обязательно чтобы разные справочники начинали счет своих строк с одного и того же числа 1.
Недостаток - база данных теперь не сможет контролировать что вы используете непротиворечивый идентификатор (можно в запись одного справочника указать номер из другого), хотя несуществующий так же нельзя будет указать (и будут работать delete cascade), так же удобной автогенерации sql не будет. Структура будет проще, так же интерфейс редактирования таких справочников может быть один вместо кучи форм и добавлять новые справочники будет сильно проще (хотя с точки зрения разработки нет особой разницы, один insert ты написал или create table перед этим)

3. не хранить справочники в базе данных вообще, т.е. за значение справочников отвечает бакэнд (хранятся в статичных файлах или в коде) самый дибильный подход, редактировать такие справочники скорее всего только руками в конфигах/исходниках. Недостатки - база данных совсем не будет знать ничего о значениях и не сможет ни проконтролировать ни помочь с запросами
Но это позволит снять немного нагрузки с базы данных, сделает структуру проще и позволит перенести управление значениями справочников на откуп ide редактора (если хранить значения справочников в коде, можно дать значениям имена переменных, так как в коде часто их так или иначе заводить придется)

Лично я третьим подходом в чистом виде не пользовался, но у меня был набор скриптов, которые из справочников в базе данных формировали код с инициализацией констант и их именами для приложения (сами справочники приложением редактироваться не могли) и был соблазн перевести эту часть базы из 'оперативной' в 'для разработчика', так как справочник это что то - отвечающее за отображение информации, но не за бизнеспроцессы (ну примерно как языковые файлы для приложения, не хранить же переводы строк интерфейса тоже в базе, ну так и справочники смогут работать как часть этого интерйфейса и тоже может требовать перевода).

Выбирать область, в которой может быть сдвиг?

Формируете маску игнорируемых областей, по этой маске заливаете "ненужные" пиксели одним цветом, а потом уже обрабатываете. В залитых пикселях движения точно не будет. =)

Задача- у статичной студии выявлять не двинул ли ведущий декорации,

Т.е. нужно обнаружить сам факт движения, а не выделить область, где оно произошло?
Я бы прошелся небольшим blur'ом по эталонному кадру и по текущему, а потом попиксельно вычел. Остаток прогнать через пороговое преобразование, если есть заметное смещение - значит, что-то не так.
Но будет работать только если освещение не меняется, а в анализируемую зону не падает тень от ведущего.
Если декорации цветные, то это можно отчасти нивелировать, работая в системе цветности HSV по каналу Hue (оттенок), игнорируя Saturation (насыщенность) и Value (яркость).

трейсбеки читайте снизу вверх.
Ошибка у вас

File "C:\Users\Student\AppData\Local\Programs\Python\Python310\lib\random.py", line 378, in choice
    return seq[self._randbelow(len(seq))]
IndexError: list index out of range

Значит пытаетесь обратиться по несуществующему индексу. Выясняйте что не так

selenium.common.exceptions.NoSuchElementException: Message: no such element: Unable to locate element: {"method":"xpath","selector":"//*[@id="icon_label"]"}

найти рабочие прокси.

message_ids=event.object.conversation_message_id

Для группы удаление сообщений происходит через conversation_message_id

Запринтите event чтобы увидеть что в нем приходит.

Файл .gitignore создают не при отправке готовой работы во внешний репозиторий, а задолго до того. Желательно даже вообще до создания первого локального коммита. Это обычный текстовый файл и он создаётся как и любой другой файл с кодом. Мак тут ничем не отличается от винды или линукса. Разве что Finder не показывает имена начинающиеся с точки. Если нажать command + shift + ., то увидишь скрытые файлы. Но мы всё равно создаём файлы в текстовом редакторе или в IDE, а не в проводнике. И редактор и Git этот файл видят в любом случае.

побезобразничаем ...

t = '4+5+3+2+3'
print(sum(int(i) for x, i in enumerate(t) if not x % 2))

#17

или

t = '4+5+3+2+3'
print(sum(int(i) for i in list(t)[::2]))

#17

Если только суммирование в инпуте:

sum(map(int, "4+5+3+2+3".split('+')))
# 17

с sympy:

from sympy import sympify
sympify("4+5+3+2+3")
# 17