Руслан .

У 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
Или это не достаточно локонично.

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

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

Можно так попробовать например:
F(X) = 30+(1-X)*20, где X - функция от t.
X(t) = sign(int(t/10)), если t меньше 10, то X всегда 0, если больше, то всегда 1.
Ну и F(0)=30, а F(1)=50.
Но есть нюанс, я не знаю разрешены ли отрицательные числа, этот вариант только для положительных t.

Может индекс поменять с product_id+prop_id на
prop_id + product_id. Отбор же по prop_id идет, а тут не попадание в первое поле индекса.

Недавно решали задачу, как пофиксить ошибку производительности в одном старом легаси без исходников. В итоге выяснилось, что менеджер памяти в одной dll иногда тормозит при выделении блоков. Пришлось патчить эту dll-ку, через установку хуков на вызовы внутреннего менеджера памяти, чтобы подменить его на другой более шустрый. Раскопать это все без хотя бы базового asm, врядли бы вышло.
А нужно это было бизнесу, т.к. переход на более свежую версию и перетестирование всего на регресс было сильно затратнее, чем локально пропатчить dll.

Можно попробовать рекурсивный CTE, только нужно убедиться, что глубина рекурсии не очень большая, не больше 50 например.
Вот тут есть пример.
https://learnsql.com/blog/recursive-cte-sql-server/
Ну и реализация будет зависеть о вашей платформы, т.к. есть небольшие различия в синтаксисе.

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

При загрузке большого сообщения на стороне клиента у вас будет около 1000 фрагметов, судя по размеру буфера.
client.recv(10000)
Т.е. будет создано порядка 1000 новых объектов типа string. Если вместо строки использовать список и делать ему apend каждого нового фрагмента, то должно быть быстрее.
Если взять ваше время загрузки и посчитать среднее время на один фрагмент, то выходит около 7мс, тут уже время создания объекта может иметь большое значение.

А если не делать REPLACE в имеющемся файле, а создать новый файл, условно C:\\m\\notice_tmp.ini и туда сохранить новую версию содержимого, после чего удалить старый файл, а новый переименовать в C:\\m\\notice.ini.