Сергей П

Представляете, если бы врачи с таким же уровнем понимания что делают делали трансплантацию органов? Нафаршировал пациента мелко порублеными топором органами донора и ждём выздоровления=).

Ваш сервис видеоконференций наверно постоянно работает с БД, это значит, что для интеграции вам нужно постоянно делать экспорты. Странное решение дампить и переносить БД целиком. Типа если у вас молоток, то вокруг всё похоже на гвозди?

Такие вещи обычно делаются в виде микросервисов. На худой конец можно сделать простенького демона, который будет ходить в БД конференций и селектить оттуда только нужные данные, и тут же вставлять в вашу другую базу в нужном формате. Не нужно ничего дампить и ковертировать, хотя наверняка и стандартными командлайнами с небольшой конвертацией SQL-кода регулярками можно добиться аналогичного результата. Но в учтите, это нагромождение непрофильных костылей будет невозможно поддерживать. Прдётся каждый раз сучить рукава и нырять в это говно, чтобы понять почему валится процесс не доходя до конца, или почему незаметно не доходят какие-то записи...

Если сделать отдельный скрипт синхронизации\. то его можно хорошо про комментировать, задокументировать, обложить тестами и проверками, снабдить внятными и понятными сообщениями об ошибках. Нагромождение пайпов с конвертерами, регекспами и пакетными файлами сделать удобным и стабильным гораздо сложнее.

Используйте профильные инструменты по назначению и не бойтесь осваивать новые. Такой вот совет.
А если ближе к вашим попыткам, то смотрите глазами, SQL вполне читаемый, можно по шагам посмотреть что не так. Есть в экспортированном SQL данные? Что это за данные? Куда они вставляются? Есть они там, куда вставляются? Просто проследите поэтапнро.

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

Конечно. Вот этот цикл совершенно не имеет никакого смысла:

for i in range(len(t)):
    tl.append(t[i])

Третий цикл тоже не нужен. Вы всё можете делать в одном цикле.
Или это вы разрешения спрашивали? Никто не запрещает.

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

Ваш подход вполне пригоден к использованию и его можно применять.
Тут надо внести ясность, что есть разница между константами и настройками. Настройки предполагается менять, их иногда "перекрывают" через параметры командной строки или переменные среды окружения.
Если вам нужны настройки, то этот вариант не годится. Используйте предложенный выше вариант с Pydantic.
Если это именно константы, их не потребуется или не скоро потребуется перекрывать, загружать из файлов, пробрасывать через переменные среды окружения, через параметры командной строки и т.д.
Если значения этих констант приемлемо хранить в репозитории, то нет ничего плохого в том, что вы группируете константы в классы. Это нормально для питона.

Но учтите, что вам может захотеться хранить в таких вот местах какие-то чувствительные, т.н. секретные данные. Например, ключи шифрования, пароли для подключения к БД или другим сервисам, ключи API, всякие токены и т.д. Такие данные опасно, неудобно и неправильно хранить в репозитории вместе с кодом. Для хранения таких параметров тоже нужно использовать библиотеки для хранения, сериализации и десериализации настроек.

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

Если вопрос стоит в том, чтобы надёжно удалить, то лучше переписать весь освободившийся объём заполнив его мусором или хотя бы нулями. В линуксе это делается простой командой, в винде наверняка есть куча утилит.
Для восстановления же нужно пробовать. Утилит тоже полно всяких. Теоретически можно.

куда копать если хочу проверить свою программу в условиях сбоев файловой системы

Копать надо в сторону документации к своему языку программирования, к библиотекам, которыми вы взаимодействуете с файлами.
Нужно делать аудит кода, понимать какие ошибки возможны в том или ином месте, в конкретных вызовах системных API прямых или косвенных. Эмулировать можно как обычно моками. Просто бросаете все возможные ошибки в моках и смотрите на реакцию тестов. Да, нужны юнит-тесты. Нужно правильно декомпозировать задачи, чтобы их легко можно было тестировать по частям, чтобы прозрачно было чем могут обернуться те или иные unhandled исключения.
Почитайте про Gracefull Degradation, про иммутабельность, журналирование и прочее, что может пригодиться для разработки надёжного кода и архитектуры.
А вы пытаетесь стрелять из ружья дробью по автомобилю, чтобы проверить его надёжность. Это не системный подход.

Так не бывает.
Нельзя сделать что-то в одном экземпляре бюджетным.
бОльшая часть стоимости смартфона (а именно о нём, как я понял, речь, раз уж упомянут Андроид), составляет инженерная разработка. Профессиональная деятльность специалистов стоит дорого и окупается только большими партиями конечных устройств.
Очень наивно полагать, что вы соберёте что-то хотя бы отдалённо похожее на заводской смартфон самостоятельно, и это будет дешевле заводского варианта.
Поясню на примере. Без всякого андроида если собрать простейшую звонилку на модуле SIM800 и ардуинке, вы вылезете сильно (в разы) за пределы стоимости аналогичного по функциональности бабушкофона. Просто потому что сам модуль стоит как простейшая готовая звонилка с экраном, цветным экранчиком и корпусом в разумном по рамеру форм-факторе без торчащих проводов и не пол кило весом.
Чтобы сделать смартфон с андроидом их готовых компонентов, вам придётся либо собирать все модули крупноблочно (блютус, вайфай, GSM из дорогих и некомпактных блоков, либо проектировать и разводить плату, что на несколько порядков сложнее и, судя по вашему вопросу, просто невозможно для вашего уровня.

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

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

Самая распространённая ошибка - это полагать, что команды в кронтабе выполняются так же как и в обычном баше. Нет.
Нужно указывать абсолютные пути ко всем файлам которые запускаете.
В данном случае это docker и head

Тут кеш ни при чем. Когда вы запускаете с одним воркером или просто дев-сервер, то запущен только один процесс. Именно его конфиг вы и апдейтите.
Когда процессов несколько, а вы выполняете апдейт только в одном, то изменение только там и остаётся. Это не кэш. У каждого процесса своя память, а ваши изменения не затрагивают код, только меняют значение переменной в одном из процессов.
Вот и весь секрет.
Ключевая ошибка вот тут у вас в понимании:

использую обновление файла конфигурации, и параметров.

Вы не трогаете файл конфигурации по факту вот тем своим кодом, что привели, но даже если бы вы в этом файле конфигурации что-то поправили и сохранили, то его нужно в каждом процессе перезагрузить. Ну сделать релоад этого модуля, например.
Вообще это не очень хорошая схема динамического обновления конфигурации.
Используйте какой-нибудь механизм pub/sub (подписок на события), чтобы отправить каждому процессу сигнал об изменении конфигурации.
Ещё можно сделать механизм обнаружения изменения конфигурации в файле, чтобы этот механизм постоянно мониторил таймштамп изменения файла и сравнивал с временем своего обновления конфигурации (в памяти). При нестыковке просто перезагружаете конфигурацию. Это будет работать в каждом процессе.
Ну или лучше погуглите готовые решения для этой задачи. Их много существует. Так будет лучше.

И да, тут надо понимать, что пока у вас простой сервер и в нем не много параметров конфигурации, можно легко контролировать каждый параметр и возможные побочные эффекты от его динамического изменения. Но в сложном проекте можно легко потерять из виду какой-то побочный эффект или неявное промежуточное состояние, когда измененный вот так вот параметр конфигурации приведёт к неконсистентности состояния всего процесса.
В таких случаях при обнаружении процессом признаков изменения конфигурации имеет смысл процессу просто самостоятельно завершиться штатно закрыв все свои соединения. Ещё хорошей идеей было бы сделать это через небольшой рандомный интервал времени, чтобы все ваши процессы делали это не одновременно.
gunicorn, кажется, должен просто запускать новые процессы взамен завершившихся, чтобы сохранить нужное их количество. Тут я не уверен, нужно смотреть. Но новые процессы будут запускаться уже с новой конфигурацией, загруженной штатно, обычным и единственным способом. За счет рандомной паузы перед самозавершением процесса вы не получите мгновенного отказа всех серверных процессов.

То, о чем вы говорите - это не какая-то отдельная программа. Код, который отвечает за такую загрузку с прогресс-баром должен располагаться частично на сервере, а большей частью на клиенте, то есть в браузере. Это значит, что этот код будет встроен в ваш сайт и на серверной и на клиентской его стороне.
Реализовать это можно разными способами, и есть много разных готовых решений для разных фреймворков. Приделать загрузку от одного фреймворка к другому в общем случае можно, но это не тривиальная частная задача, поэтому искать надо способ сделать это в вашей экосистеме, а не отдельно.

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

Если вам не понятно то, что я тут рассказал, то, увы... Пока что вам будет не по силам такое реализовать. Опыта и знаний маловато. Учитесь, или идите к фрилансерам, ну или более детально формулируйте свой вопрос. Потому что по нынешней его формулировке выходит, что вам нужна подробная индивидуальная лекция о том, как работают веб-приложения, причем для совершенно неподготовленного человека. Это часов 15 индивидуальных занятий.
Вы же понимаете, что этот ресурс не про такое?

Скорее всего вы применяете клиентское API телеграма не по назначению или вопреки лицензии. Например, вы, может быть, рассылаете спам, или скам, а может быть делаете что-то ещё, что противоречит добросовестному использованию сети.
Конкретной причины, по которой вас блокируют вам никто скорее всего не скажет. В таких случаях самое эффективное - это максимальнео расплывчато описывать причины и критерии возможных блокировок, чтобы играясь с пороговыми критериями злоумышленники не могли подстроиться под ограничения.

Скорее всего ограничения и критерии, по которым вашу деятельность пресекают, не заключаются в чем-то одном. Скорее всего критериев много и они не однозначно влияют на принятие решения о блокировке. Другими словами, если быть по ту сторону баррикад от вас, то причины блокировок нужно сделать максимально многофакторными, диверсифицированными, неявными и нечеткими. Где-то нужно даже вводить рандомизацию и отложенную блокировку, если вы предпринимаете серьёзные меры, чтобы ваш софт притворялся валидным штатным клиентом. В вашем же случае, видимо, паттерн использования протокола и АПИ выдаёт вас мгновенно.

Подумайте чем ваш "клиент" телеграма отличается от добросовестно выполненного клиента для штатных целей? Может быть он не сохраняет контактов? Может быть коннекты идут из одной подсети и она уже "на особом счету"? Может быть На ваши сообщения много жаловались, и теперь отдельные специальные эвристики вылавливают клиентов, похожих по паттерну на ваши и банят их сразу же?

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

Интересная задачка. Никогда ее не решал, поэтому пользу от моего ответа вам, наверно, не будет, но...
Вы вот чем сформировали изображение проекции кадров на первой картинке в вопросе?
Если вы смогли спроецировать кадр, то также можно спроецировать и каждый пиксель. Формулы те же, вопрос интерполяции. Нужно просто спроецировать ваши фото на одну картинку, а при одинаково настроенной фиксированной экспозиции по цвету границ видно быть не должно.
Также можно откалибровать и поправочные искажения локальных участков для каждой камеры. Это будут векторные поля, сформированные размытием опорных поправочных векторов при калибровке.
То есть берете кадры звёздного неба, отмечаете одинаковые точки на ваших проекциях, двигаете проекции, чтобы точки совпали и надеетесь, что ваша монтировка не погнётся=).
Сама склейка будет происходить попиксельно. Каждый кадр попиксельно проецируется в отдельный слой с вдвое бОльшим разрешением, так каждый проецируемый пиксель будет немного четырёхугольником с вещественными координатами, а затем спроецированные полигоны растеризуете и усредняете перекрытия.
Задачка выглядит не особо сложной. Основная задача в подборе формул проецирования.

https://pages.github.com/

https://habr.com/ru/articles/678330/

Во-первых, "слагаемые".
Во-вторых, почитайте код вашей рекурсивной функции, он выдаёт количество, а не сами варианты сложения. Если не можете это понять из кода, то вам рано такие задачи. Серьёзно.
А ошибка у вас из-за того, что такой алгоритм упирается в размер максимальной глубины рекурсии. Если хотите такие значения считать, делайте итеративный алгоритм, а не рекурсивный. Если эти слова тоже для вас новые, то надо браться за учебник, эта задача слишком сложна будет для вас.
Успехов.

А в чем проблема на гитхабе поискать-то?
https://github.com/search?q=fastapi+example&type=r...