Zanak

binwalk вам в помощь. дальше по ситуации. окажется пых, обойдетесь малой кровью.

Однозначного рецепта нет.
Самый простой случай: вы строите проект на основе какого - либо фреймворка, и подтягиваете другие возможности, прежде всего БД, может быть, редиску или кролика, в качестве вспомогательных элементов для реализации задач проекта. Здесь все просто - фреймворк определяет размещение, количество и наполнение файлов. Если речь о web фреймворках, и количество страниц заметное, то, не возбраняется разложить ендпойнты по пакетам, согласно их логической близости.
Случай посложнее - монолитный сервис. Здесь в дело вступает декомпозиция по зонам ответственности, авторизация и регистрация, контроль прав, работа с данными проекта, обработка запросов, мониторинг, статистика, логгирование и так далее. Здесь, я, обычно, разделяю код по пакетам, чтобы не смешивать задачи, и сохранять его "обозримость".
Если, например, вы рассматриваете микросервисный проект, где подбираете инфраструктуру, и с помощью отдельных процессов выстраиваете взаимодействие между элементами, то, каждый микросервис, по сути, является отдельным приложением, которое может разделять, а может и нет, кодовую базу предметной области с другими.
Коллеги вспомнили о структурных паттернах, но, позволю себе обратить внимание на то, что данные шаблоны не регламентируют разделение кода по файлам. В них речь идет исключительно о способах решать конкретные проблемы.
Если смотреть на вопрос со стороны ТЗ, то, я стараюсь выделять минимальные смысловые части, и реализовывать их, как сочту правильным/удобным. Например, написано: работа пользователя с данными возможна только после авторизации, новые пользователи обязаны пройти процедуру регистрации. Из этого вытекает такая последовательность реализации: создаем миграцию для создания таблицы пользователей, создаем процедуру регистрации, создаем процедуру проверки данных авторизации, организуем хранение информации об авторизованных пользователях "кто онлайн". Миграции, как правило, хранятся пофайлово, манипуляция с учетками, может, относится к работе с объектом "пользователь", контроль прав может лежать в отдельном пакете, и подключаться по необходимости.

На мой взгляд, получается, как-то так.

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

PS. Если смотреть на код в контексте неожиданных конструкций, странно, что вас не заинтересовал код в 132 строке. Я сходу не сообразил, зачем там select.

Так web приложений или программ? Там есть совпадающие моменты, например - отсылка запросов в БД, но внутренне это довольно разные по устройству вещи.
Языка может хватить и одного, главное, чтобы в нем присутствовали требуемые сейчас вещи. Будет он скриптовой или компилируемый тоже почти не важно.
На счет инструментов - все зависит от языка и команды, скорее даже от ее лидера. Ну, может еще от заказчика. Но точно не от архитектора.

В общем, как понимаю, вам интересна не работа архитектора, а позиция сеньора или лидера, если так:
- вам необходимо выбрать язык программирования, которым вы будете заниматься ближайшие лет 5 и освоить его
- по мере освоения языка, осваивать инструменты, фреймворки и лучшие практики языка
- все это время, ОБЯЗАТЕЛЬНО ПРАКТИКОВАТЬ ЯЗЫК, потому что это искусство, как и любое другое, без практики не освоишь
- подбирать проекты, в которые включаетесь, чтобы улучшать свой опыт и навыки
- гнать разного рода советчиков, типа grokking ... interview, хотя бы на первых порах, если только вашей задачей не стоит - убедить окружающих, что вы знаете больше чем есть на самом деле
- с курсами сложнее, возможно, не все из них пустышка, но мне не повезло. лекции, записанные 10 лет назад, формальные задания, контрольные вопросы, направленные на выяснение, досмотрел ты ролик до конца, или просто открыл учебник и все изучил сам. если бы их прохождение не было настоятельной просьбой работодателя и не оплачивалось им же, я бы попросил вернуть деньги после первого занятия

Обычно, компании оставляют за собой, как минимум, имущественное право на весь ваш код, изготовленный вами на возмездной основе. Соответственно, распоряжаться самими правками вы не можете.
Договор о неразглашении, по идее, должен защищать от создания собственных версий патчей или публикации информации о способе исправления проблемы, если вы получили это знание в рамках исполнения своих служебных обязанностей.
По этой причине, кмк, есть 2 варианта, как поступить. Катить патч от имени компании, с указанием авторства, если нет возражений владельца, или попросить "нейтрального" коллегу со стороны закатить патч от своего имени, если всерьез опасаетесь последствий. Вариант "партизанить" я опускаю :)

Навешиваем ссылки L и R на тот массив что раньше начинается и оставшийся.
Далее логика такая, в цикле читаем, пока не кончился оба массива:
- из L массива, пока не кончился R и L[i] <= R[j], либо не кончится L, двигаем значение i
- далее симметрично, читаем из R массива, пока не кончился L и R[j] <= L[i],либо не кончится R, двигаем значение j

Циклов пожалуй не меньше вашего, так что, дело вкуса, какой вариант больше понравится :)

1. А зачем отслеживать местоположение такси? Пусть таксист сам, когда готов, или за пару минут до того, автоматически, с известной периодичностью, стучится на сервер запросом, типа: "я здесь, ..., ищу заказ, чего есть". Сервис вычисляет расстояние до активных клиентов и кидает варианты о тех, например, до кого менее 3 километров. Такси, чей аппарат выключен, или находится в пути, не тратится на интернет и не создает ненужной нагрузки на сервере.
2. Новый заказ должен попадать тем, кто может его взять сейчас, или через несколько минут, разве нет?

Протоколы обмена и способы хранения данных на сервере могут быть почти любые, http/rest/websocket, на чистых sql базах, или какой нибудь nosql, с очередями или без. Чего лучше знаешь, то и используй, кмк.

А зачем метакласс? Чтобы закрепить интерфейс, достаточно породится от абстрактного родительского класса. А для постройки конкретного класса - шаблон "фабрика" вам в помощь.
Как вариант - можете поиграться с importlib и грузить модули по имени, в стиле а-ля плагин.

Описание объектов, как языковая конструкция, имеет 2 предназначения.
Объекты, как способ организации кода. Мы в одном месте помещаем все данные и функции по их спользованию, относящиеся к одной функциональной части приложения. Синтаксис объявления объектов логично изучить где - то после синтаксиса описания функций.
Объекты, как способ проектирования сложных приложений, вы будете осваивать позже, когда синтаксис совсем освоите. Первые, с чем, скорее всего, познакомитесь будут шаблоны проектирования. Шаблоны - это типовые способы использования большого количества разных объектов. Многие web фреймворки реализуют известный шаблон MVС, который предлагает разделять приложение на части (M - model, здесь все для работы с данными, V - view, здесь все для отображения данных модели, C - controller, это тот, кто использует модель для получения данных и view для его правильного отображения, например, в виде json, вместо полноценной страницы, в ответ на запрос пользователя). Использование шаблона для построения приложения не ограничивает нас в использовании других шаблонов для его частей. Например ORM, популярный шаблон по работе с БД. Самому вам врядли придется его реализовывать, но вот использовать чужие реализации, почти наверняка. Со временем вы научитесь не только выделять типовые шаблоны в задаче, при проектировании решения, но и в коде ваших коллег, для анализа не только каждой отдельной функции, но и устройства приложения в целом.

Каждый фреймворк имеет свое комьюнити, которое будет топить за него.
Единственное отличие джанги от многих, если не всех, фреймворков - это наличие админки из коробки (на мой взгляд - достаточно типовой админки, и если ваш проект подразумевает широкие возможности для администрирования, то лучше этот момент не рассматривать). Если админка не актуальна, например, вы пишите чистый api и убираете всю отрисовку на сторону клиента, то здесь выбор сильно расширяется и flask с django становятся одним из возможных вариантов.
Мегаглобальных различий между сабжевыми фреймворками по удобству, наличию информации, готовых модулей, или отзывчивости комьюнити в общем - то нет. Говорят, что flask быстрее, но сам не мерил, поэтому наверняка сказать не могу.
Выбирайте что вам ближе, и более подходит для решения именно вашей задачи и вперед.

Для ОС почти нет принципиальной разницы между процессом и потоком. При создании процесса происходит выделение нового куска памяти, при создании потока - это не обязательно происходит, поток имеет доступ к памяти родителя, процесс нет. Тоесть, в контексте вопроса можно ограничится разговором о потоках.
Потоков может быть столько, сколько позволяет память, даже на однопроцессорной и одноядерной железке.
Активность потоков может управляться на нескольких уровнях. Во первых, ОС может в любой момент тормазнуть исполнение потока. Даже если этому и можно помешать, врядли это легко, да и врядли нужно это делать. Среды исполнения, иногда, позволяют указать, сколько потоков запустить для исполнения программы. Например среда исполнения erlang или go позволяет программам создавать не дорогие потоки ОС, на создание которых уходит масса времени, а более легкие, жизненным циклом которых сама среда и управляет. Происходит отображение N потоков программы на M потоков ОС, которые запрашиваются один раз, при старте.
Поток может находится в одном из состояний: спит - когда планировщик его остановил, активен - когда поток получил управление, заблокирован - когда поток ждет какое - то событие или окончание какого - то действия, например прихода данных по сети, ошибка - когда происходит обработка ошибки или освобождение ресурсов и смерть потока.
Вопрос оптимальности создания более одного потока/процесса всегда следует рассматривать в контексте конкретной задачи. Даже при неблокирующем обмене данными между потоками, как минимум, переключение потоков, если речь не идет о количестве потоков меньше или равном количеству присутствующих ядер, имеет свою цену по времени. Подозреваю, многопоточная программа начинает выигрывать у однопоточной, когда количество потоков, которым надо исполнятся паралельно не превосходит количество доступных ядер. Как только потоков становится больше, в дело приходится вступать планировщику, и естественно, он работает не мгновенно.
Вопрос оптимальности архитектуры тоже, на мой взгляд, не имеет общего ответа. Для вычислительных задач может оказаться сравнимо, использовать один двухядерный процессор, или материнку с поддержкой 2 процессоров, а, например, для запуска веб сервера и БД к нему вообще лучшим вариантом может оказаться два независимых компютера.

Не может найти имя для открытия соединения. Проверте наличие имени в DNS.

Если это

If event.text.lower() == ‘Промокод’:
    ...

копипаста из вашей попытки решить вопрос, то условие ни когда не сработает.
По api вконтакте не специалист, но правдоподобный ответ легко гуглится.

Не очень понял, при каких обстоятельствах возник этот кейс, поэтому вопросы:
- расширить класс X до класса N разве не означает, что N является потомком X?
- в методе handler родитель создает инстанс потомка, вы уверены, что это правильно?

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

zip забыли :)

l1 = [1, 2, 3, 4, 5, 6, 7]
l2 = [5, 4, 8, 3, 7, 8, 9]
l3 = [l * r for (l, r) in zip(l1, l2)]
print(l3)