Руслан .

Разница еще может быть, если в расчетах используется не подходящий тип данных. Например можно float на decimal заменить и проверить результат.

Асинхронность подразумевает что в любой момент времени работает только один поток, тут нет никакой конкуренции. Сначала одна часть программы поменяет значение переменной, затем другая использует новое значение.

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

Возможно это будет полезно.
https://steps3d.narod.ru/tutorials/lighting-tutori...
Тут описание упрощенных моделей освещения, можете выбрать что лучше подходит.

Может оценивать не только победу/поражение, но и оценку последей позиции?
Условно бот победил с перевесом в n фишек и этот n учитывать в оценке.

В cgi заголовок запроса от тела отделяется одной пустой строкой. Попробуйте добавить print('') перед выводом user_info. Может клиент ожидает тело зпюапроса и поэтому не завершает его.

Если совмем небольшие суммы. То можно принимать деньги от заказчика задачи как плату за мобильную связь и со счета телефона переводить исполнителю. Но это будет такое себе и со времене это могут прикрыть.

Была похожая история. Проверьте что при закрытии приложения, оно не зависает при попытке закрыть коннекты с бд. Лучше коннекты до деструктора закрыть.

У aссess как и у sqlite только один процесс может быть подклбчен к бд на запись. Если бы flask-и закрывали за собой все коннекты сразу после использовпния бд, то возможно оно бы заработало.

А если взять вме монеты и положить в список.
Затем отсортировать по номиналу.
Затем методом двух указателей идти и набирать нужную сумму.
По идее когда указатели встретятся где-то в середине списка д.б. найдены n вариантов набора суммы.

Общее максимальное количество можно оценить взяв сумму номиналов всех монет и поделить на сумму, которую нужно набрать. Это для контроля результата.

Если передать на вход действие не 1 и не 2, то все упадет с ошибкой, т.к. функция в словаре move не будет найдена.

Использовать глобальные переменные это антипаттерн. Я про переменные key и a. Их можно было бы передать как параметры.

Для определения кода буквы можно использовать функцию ord и тогда не нужно будет пользоваться списком символов для вычисления индекса символа.

В качестве уникальной ссылки можно использовать обычный guid. Почти нулевая верятность дублирования.

Жмите Yes :) . Там же написано, что может вести себя неожиданно, но может же и нормально.

Может в кодировке дело? Попробуйте вместо
charset=utf-16 установить charset=utf-8.

Вот тут есть хороше описание.
https://github.com/eclipse/paho.mqtt.python#networ...

Можно найти ближайшие к началу периода пн и вс. А дальше с помощью date_add прибавлять к ним по 1 неделе пока одна из дат не вылетит за дальнюю границу вашего диапазона

Что-то типа такого?
https://docs.python.org/3/library/functions.html
Или это не достаточно локонично.

А если заиметь список в котором ссылки на диапазоны упорядочены по дате начала и чем-то похожим на бинарный поиск искать нужный диапазон, т.е. дата начала диапазона меньше либо равна дате поиска, а дата окончания больше (тут не ясно брать дату включительно или нет) . Список вроде проще построить и использовать чем дерево.

Но правда не ясно как решать коллизии, если например диапазоны одинаковой длинны пересекаются со смещением даты начала, то какой диапазон выбрать не ясно, если точка поиска попадает в область пересечения таких диапазонов.