как пошагово отлаживать python-приложение?

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

взаимодействуют как однопоточные

ЛОЛ ЧТО? Контейнеры у тебя в одном потоке что ли выполняются?

многопоточность даже не впилили, потому что она не нужна

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

кажется, я сломался об настройку wifi, даже кажется в режиме ad-hoc и может быть еще bluetooth, когда надо было сделать это быстро что-бы работать, а тогда в генте не было networkmanager’a, sabayon мне не хотелось ставить и я просто поставил какую-то убунту

ну в том то и проблема, что неведомые проблемы с рантайм типизациией плохо прослеживаются, даже там где приделали гварды (python, ts, контейнерные типы жабе), во время работы приложения данные могут заехать не тех типов или не известно где и отловить это можно только при пошаговом выполнении. При статической типизации большинство таких проблем отловит компилятор и будет некоторая уверенность, что контракт будет соблюдаться.

Да я в шоке просто. Python - это основной язык генты, на нём там всё. И при этом они не сделали полностью опенсорсного графического отладчика (а всего-то надо было опакетить PyDev для Eclipse).

кстати, я на генте доразвился до каких-то штук на с++, типа paludis, они работали намного быстрее и круче, а сами ebuild’ы насколько я помню скорее на bash, чем на python

время работы приложения данные могут заехать не тех типов или не известно где

И будет ошибка про несоответствие типов, с номером строки и чаще всего с самими данными, вызвавшими ошибку.

и отловить это можно только при пошаговом выполнении.

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

Получается что вся затея с дебагером ради столбца справа?

Опять набежали луддиты, серьёзно рассматривающие отладку через принты. Акститесь. Принты для логов. Отладка через отладчик.

Перезапускать программу, чтобы добавить принт для соседней переменной это тупость. Особенно учитыва, что ошибка может быть далекто не в функции main. И тогда придётся каждый раз совершать некие действия, чтобы воспроизвести баг.

В то время как в отладчике можешь сразу посмотреть весь стек вызовов и все переменные. Обычно в начале отладки есть только догадки куда смотреть и поэтому заранее расставить все нужные принты невозможно.

Да все это понятно, если было бы так просто.

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

ради столбца с актуальными на момент воспроизведения значениями, бывает лагоритм на три класса, но ошибка аномальная и проявляется только на 50ой итерации когда за окном ниже -10и и тут принты дадут кучу мусора из которой проблему раскопать гораздо сложнее, а иногда для понимания надо прямо походить вместе с рантаймом и посмотреть как он себя ведет

И будет ошибка про несоответствие типов, с номером строки и чаще всего с самими данными, вызвавшими ошибку.

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

бывает лагоритм на три класса, но ошибка аномальная и проявляется только на 50ой итерации

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

в питоне будет ошибка в рантайме,

Везде будет ошибка в рантайме, в любых managed-языках. И в петоне и в джаве и в шарпе - везде будет ошибка в рантайме.

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

Звучит как фобия, честно. Не надо бояться машин, они хорошие )

Я обычно просто вырезаю алгоритм и тестирую вне сложного приложения в таких случаях.

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

Везде будет ошибка в рантайме, в любых managed-языках.

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

Звучит как фобия, честно.

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

а что-то вроде сложения строки с числом умноженным на указатель в жс, т.е. не вполне ожидаемый результат,

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

Буду благодарен, если вы приведете пример такого «не вполне ожидаемого результата» (если только это не race condition), мне например в голову таких примеров не приходит.

да запросто:

1. у вас есть фронт на ts, у которого где-то в моделях объявлено поле с типом «строка», но бекенд что-то там поменял у себя и вместо того где была «строка» стало «число», поскольку выполняется в браузере у вас не ts а js в котором стараниями мелкососа нет гвардов, то «число» запросто без ошибок и ворнингов присваивается вместо «строка» и никакого нормального реального способа, кроме того что-бы «кастануть в строку, потом обратно в число, потом обратно в строку чтоб уж наверняка» у вас в принципе нет

2. в пипоне я просто заворачивал код с ошибкой присваивания неверного типа в метод и он не порождал ошибок (на компиляции в байткод и запуске) пока эта строчка кода реально не выполнится, т.е. если вы не покроете такой код 100% тестами у вас потенциально будут ошибки в коде, которые будут вылазить только на проде у пользователей

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

у вас есть фронт на ts, у которого где-то в моделях объявлено поле с типом «строка», но бекенд что-то там поменял у себя и вместо того где была «строка» стало «число»,

Рад за ваш бекэнд, коль уж он эволюционировал до того, что сам стал принимать решения. Видимо скоро он осознает себя и пойдет искать Сару Коннор.

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

В котором (опять же внезапно) есть четкие правила насчет поддерживаемых типов.

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

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

поскольку выполняется в браузере у вас не ts а js в котором стараниями мелкососа нет гвардов, то «число» запросто без ошибок и ворнингов присваивается вместо «строка» и никакого нормального реального способа,

Как говорила моя бабушка «да но нет».

Да, выполняется Javascript код, в который происходит трансляция из Typescript. Да, в Javascript нет строгой типизации, как в Typescript, поэтому транслятор ее стирает. Но помимо этого он также вставляет проверки на тип, которые берут и отрабатывают в рантайме, уже на Javascript. Вот такая коварная подлость.

т.е. если вы не покроете такой код 100% тестами у вас потенциально будут ошибки в коде, которые будут вылазить только на проде у пользователей

Не бывает 100% покрытия тестами для кода сложнее «Hello World», поэтому да, будут. Да, будут вылазить.

Чтобы сие не стало сюрпризом именно на продакшне, помимо юнит-тестов существует еще функциональное и интеграционное тестирование и даже «smoke-testing», которое каким-то чудным образом к запрещенным веществам отношения не имеет.

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

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

И немедленно умираете в муках от рака простаты. Либо от руки вашего тимлида или кто там у вас код проверяет.

так вы просили примеры чтобы их обоссать? вы написали как-будто не уловили сути хотя я уверен, что вы в состоянии ее понять, она в том, что если вы обмениваетесь данными с внешней системой/рантаймом то там будет место для рантайм ошибок, а в большинстве случаев даже для скрытой их формы, т.к. практически нигде контракты из экономии не проверяются в рантайме. В тс->жс у вас все станет обжектом, а примитивы будут кастоваться автоматически, а ещё переприсваиваться и зануляться). Т.е. в случае с динамическими языками сама среда выполнения интерпретатора является небезопасной, просто «все привыкли». Ну а то что применяют в микросервисах и генераторах это примерно как юнит-тесты, которые хороши только для идеальных условий и чтобы пустить пыли в глаза неофита и лошпедам и отболтатьтся, что технология отличная, но программисты плохие.

Т.е. в случае с динамическими языками сама среда выполнения интерпретатора является небезопасной, просто «все привыкли».

Именно так и обстоят дела, о чем я и хотел донести мысль. И под «привыкли» подразумевается огромный и отлаженный механизм реагирования на рантайм ошибки, который как раз и нивелирует смысл в использовании отладчика.

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

А когда в фоне висит какой-нибудь мессенджер

Задача - обработать десятки тысяч входящих сообщений в секунду.

Архитектура микросервисная - есть listener, который принимает сообщения и складывает во внешнюю очередь, есть handler, который забирает сообщения из очереди и обрабатывает. Можно поднять сотню однопоточных инстансов обоих, потратить over9000 ресурсов на каждый из них и задолбаться это дело поддерживать, потому что выяснить, где застряло каждое конкретное сообщение, невозможно. А можно и то, и другое сделать многопоточным, поднять по десять инстансов и пить кофе, пока оно там себе все эти сообщения молотит.

Когда указываешь направление в сторону стены, всё-таки иногда думай, что есть задачи, с которыми ты не сталкивался.

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

В нормальных языках ничего перезапускать не нужно.

Я говорил и говорю исключительно про десктопы, потому что я сам пользуюсь десктопом.

Блин. Опять я забыл libastral подгрузить.

Ну, по моим примерам можно же догадаться

этот механизм вам в лучшем случае пишет «где-то произошла какая-то фигня», ну в самом лучшем случае понятно где, т. е. куда ошибка, которая ещё не ясно где произошла зааффектила

Все по секретным документам.

Ну ладно ок, такое действительно бывает. Хотя все реже и реже.

Давайте зайдем с другой стороны, есть вот такой проект: https://github.com/getsentry/sentry

На петоне, достаточно большой и сложный. Покажите как бы вы его отлаживали.

Это не с целью вас как-то оскорбить, просто я на самом деле уже лет так 15 не использую отладчик нигде, ни в джаве, ни в typescript, ни тем более в петоне.

Остались только gdb, Visual Studio под вендами и adb ради Андроида.

Задача - обработать десятки тысяч входящих сообщений в секунду.

С такой постановки начинается либо тупой вопрос на собеседовании либо операция по смене пола. И я очень надеюсь что это ты так тренируешься перед собеседованием в Гугле а не бреешь ноги и примеряешь чулочки.

В реальной работе же, подобный заход закончится избиением ногами от архитектора проекта или кого-то похожего (с бородой и ответственностью), который тебе доходчиво пояснит что помимо входящих сообщений бывают еще и исходящие (и никакой пользователь не выдержит 10к СМС за раз), что есть время устаревания и последовательности сообщений, которые определяют связанные действия (например классический CRUD: создание-обновление-удаление записи)

Вообщем не надо такими словами бросаться, беду накличешь.

помимо входящих сообщений бывают еще и исходящие

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

никакой пользователь не выдержит 10к СМС за раз

В каком месте я писал про какого-то одного пользователя?

что есть время устаревания и последовательности сообщений

Как медленная последовательная обработка вместо быстрой параллельной решит проблему устаревания?

определяют связанные действия

Ты не поверишь, но иногда это решается банально с помощью формата входящих сообщений с соответствующими индентификаторами. Это придумали ещё когда бородатые архитекторы, пинающиеся ногами, ходили пешком под стол.

например классический CRUD

А кроме классического CRUD задач в природе, видимо, не существует.

Вообщем не надо такими словами бросаться, беду накличешь.

Пока что я вижу, что словами бросаешься только ты.

Может быть ты и специалист по бритью ног и колготкам, но вот как архитектор ты пока что выглядишь не очень.

Как медленная последовательная обработка вместо быстрой параллельной решит проблему устаревания?

Речь не про последовательно/параллельно а именно про устаревание - представь что твой сервис отправляет PUSH-уведомления пользователю. Очевидно что нет смысла отправлять пуши о событиях, которые случились неделю назад.

Ты не поверишь, но иногда это решается банально с помощью формата входящих сообщений с соответствующими индентификаторами.

У тебя в очереди лежат три сообщения: 1. удаление записи, 2. создание новой записи 3. обновление полей записи

Теперь представь что последовательность выборки из очереди - произвольная а ID записи это UUID.

Достаточно доходчиво или картинку с х#ями нарисовать?

Может быть ты и специалист по бритью ног и колготкам, но вот как архитектор ты пока что выглядишь не очень.

И тем не менее вот такого у тебя пока нет, а за архитектуру платят все же мне а не тебе. Жизнь несправедлива, я знаю.

У тебя в очереди лежат три сообщения: 1. удаление записи, 2. создание новой записи 3. обновление полей записи

У меня не лежат в очереди такие сообщения. Ты в курсе, что CRUD'ом мир не ограничен? Иногда бывает большой поток входящих данных, а не операций. И данные, ты не поверишь, тоже иногда нужно обрабатывать очень быстро.

И тем не менее вот такого у тебя пока нет, а за архитектуру платят все же мне а не тебе.

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

У меня не лежат в очереди такие сообщения.

Замечательно, поздравляю.

Ты в курсе, что CRUD’ом мир не ограничен?

Читай ниже и удивишься.

Иногда бывает большой поток входящих данных, а не операций. И данные, ты не поверишь, тоже иногда нужно обрабатывать очень быстро.

Дай догадаюсь: статистика по клиентам, по использованию услуги?

Не поверишь, но так бывает что клиенты уходят а услуги устаревают. Что происходит дальше?

Па-бам! Сообщение об удалении.

Так что нравится тебе или нет но CRUD он везде, поскольку это базовый набор операций над данными. Нет ИТ-системы без CRUD. Cовсем нет, даже если ее написали на Хаскеле.

иначе ты только обесцениваешь визиточку на фотке.

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

Дай догадаюсь: статистика по клиентам, по использованию услуги?

Нет, не угадал.

И судя по остальным вопросам, что-то объяснять бессмысленно.

Я не пойму, что ты мне пытаешься доказать? Что нельзя параллельно принимать десятки тысяч сообщений в секунду? А что тогда с ними делать? Отбрасывать с «Service unavailable»? Давай-ка расскажи.

Что нельзя параллельно принимать десятки тысяч сообщений в секунду?

Что нельзя так ставить вопрос вообще, никогда. Прием/отказ это технические термины, не бизнес-логика.
Если у тебя например биллинг и считается трафик то речь не про прием или абстрактную «обработку» а про вполне конкретную запись.

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

Видимо не зря все же у меня была такая визитка, согласись.

Видимо не зря все же у меня была такая визитка, согласись.

Пока что не соглашусь. Ты на ходу придумываешь какие-то надуманные проблемы, о которых в исходном сообщении не было и не должно было быть речи.

Запись - проблема, сохранение и обновление состояния - проблема, но не прием.

Я вроде явно в самом начале написал. Принять сообщение и сложить в очередь. Именно поэтому эта задача параллелится. Консистентность, время жизни, актуальность, валидность и прочие свойства потока сообщений проверяются на следующих шагах обработки(каким образом, я уже намекал пару раз). Потому что если сообщения не были получены, то и обрабатывать нечего. Что здесь может быть непонятно такому матёрому архитектору бритых ног и колготок, я не знаю.

Принять сообщение и сложить в очередь.

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

Поэтому не может быть бизнес задачи вида «принять сообщение и сложить в очередь».

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

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

С одной стороны каждый криворукий мудак, допущенный до проектирования ИТ-систем увеличивает тем самым потенциальный объем моей работы, что безусловно хорошо.

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

Поэтому и стараюсь просвящать, по мере сил.

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

В каком месте я вообще говорил хоть слово о бизнес-требованиях? Процитируй, пожалуйста. Я привёл пример задачи, где параллельная обработка входящих сообщений лучше, чем последовательная. Да, именно технической задачи. Ты не поверишь, но слово «архитектура» не зарезервировано исключительно бизнес-логикой. Именно поэтому я не описывали ни то, какие сообщения, ни что с ними надо делать, ни остальных подробностей. В рамках примера - это не важно.

Задача - обработать десятки тысяч входящих сообщений в секунду.

Не ты ли написал?

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

Ты можешь сделать какие-то выводы из написанного мною и что-то применить в своей работе на практике, а можешь в очередной раз написать что автор - дурак.

Что меня разумеется никак не удивит и ни на что не повлияет.

Не ты ли написал?

У нас с тобой, видимо, какой-то разный русский язык. Я в своей фразе не вижу ничего про бизнес-требования. Если тебя смутило, слово «обработать», то я снова открою тайну. Оно применяется например в TCP/IP, как «обработать входящий tcp-пакет». Или это тоже бизнес-логика?

Ты можешь сделать какие-то выводы из написанного мною

Большое спасибо, но ничего нового я не узнал. :)

Оно применяется например в TCP/IP, как «обработать входящий tcp-пакет».

Но разбором TCP-пакетов ты при этом не занимаешься, ведь так?

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

Ты же поставил под сомнения мои навыки и хотел убедиться в профессионализме, не?

Но разбором TCP-пакетов ты при этом не занимаешься, ведь так?

Как Senior SRE инженер(хотя я себя по привычке зову админом), я как минимум должен очень хорошо понимать, как эта обработка происходит.

Из выше сказанного понятно, что я не разрабатываю самолично какую-то конкретную систему. Я (и мои коллеги) участвую в разработке многих систем компании в той части, которая касается отказоустойчивости и доступности. В том числе часто приходится спорить с архитекторами, когда их требования расходятся с суровой технической реальностью. Ищем компромиссы. Благодаря этому мне про бизнес-логику приходится знать больше, чем хотелось бы, но меньше, чем нужно для описания полной «бизнес-архитектуры» какой-либо из систем, зависящих от меня.

Ну а почему я поставил под сомнения твои навыки, я выше написал. Спишем это на то, что ты решал бизнес-задачу, а я техническую.

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

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

Спишем это на то, что ты решал бизнес-задачу, а я техническую.

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

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

Благодаря этому мне про бизнес-логику приходится знать больше, чем хотелось бы

Это подход именно что сисадмина, но точно не архитектора.

я знаю как делать твою работу и в чем она заключается

Ох, как бы мне хотелось, чтобы это было так. :) Жизнь стала бы намного проще.

Жизнь стала бы намного проще.

Ты лишь маленький винтик на зарплате, причем 100% белой, с ДМС и страховкой. С нулевой юридической ответственностью, без риска потери репутации или работы.

У тебя есть выходные, праздники и больничные, при этом не бывает звонков, которые ты не можешь не принять.

Тебе никто не угрожал расправой или преследованием в суде за проваленный проект, никто не требовал вернуть оплату, у тебя не было разногласий с руководством влияющих за размер зп.

Я ничего не забыл?

Теперь зайди в кабинет к СТО и обними его бедного )

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

С учётом моих доступов подобные риски в договоре описаны.

при этом не бывает звонков, которые ты не можешь не принять.

И снова мимо. Но справедливости ради, это что-то крайне страшное должно случиться.

В остальном, да. )

Теперь зайди в кабинет к СТО и обними его бедного )

Передам от тебя привет, когда встретимся на следующем корпоративе. ) Мы в разных городах.

С учётом моих доступов подобные риски в договоре описаны.

Да ну, неужели «коммерческая тайна» и «материальная ответственность» у банального SRE? На уровне фантастики.

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

Лет пять назад в одном международном банке была и тайна. До сих пор не имею права его название произносить. В октябре срок действия NDA истекает.

банального SRE

А говоришь, что знаешь мою работу. :)

А вот действия, которые могут привести к существенным убыткам, вполне мне доступны.

Угу, минут на 15 процессинг положить, пока бекап не восстановится. Прям «Доктор Зло» во плоти. Если банк нормальный - должны быть резервые каналы, резервное железо и резервное вообще все, вплоть до второго SRE.

Лет пять назад в одном международном банке была и тайна. До сих пор не имею права его название произносить. В октябре срок действия NDA истекает.

NDA и в лучшие годы на РФ не распространялся если что, уже на ЛОРе кому-то писал на эту же тему.

Дело тут не в NDA или названии банков (я сам работал в банке и не одном) а банально в твоем нежелании и непонимании.

Но это все очень сильно далеко ушло от топика, поэтому предлагаю тему закрыть, надоело.

выглядит как вебня на жанге, в норме это должно работать так:

1. открываем сорцы в среде разработки

2. расставляем брейкпоинты в интересующих местах кода

3. нажимаем кнопку «Запустить как дебаг»

4. совершаем действия по воспроизведению пока брейк не словится

5. отлаживаем

если отлаживать надо какой-то «бекграунд/мидлаваре» функционал, пишем тест и дальше делаем все тоже самое. Если в пипоне это делается как-то по-другому, это минус пипону, а не «ненужна» откровение

нажимаем кнопку «Запустить как дебаг»

Ее не будет, поскольку это не хеллоу ворд и там нет очевидного места запуска.

совершаем действия по воспроизведению пока брейк не словится

где-то 90% логики в данном проекте это сложная фоновая обработка, которая начинается с внешнего вызова REST метода.

Немного расскажу что это за проект, поскольку часто его гоняю. Это открытый сервер телеметрии. В конечных приложениях на Java/Node.js/Angular/React/и тд (там очень много что поддерживается) подцепляется специальный агент, который в случае внутренней ошибки шлет трассировку и детали на этот сервер.

В работе выглядит как-то так

Вещь чрезвычайно полезная и важная, точно не описываемая как:

вебня на жанге

Но при этом оочень много фоновой обработки, до которой отладчиком не добраться никак.

пишем тест и дальше делаем все тоже самое.

Чтобы написать новый тест для проекта такого масштаба, придется заморочиться на уровне участия в разработке. Это сложно и долго.

Ради одной отладки я бы не советовал.

Может есть еще какие идеи от «теоретиков программирования»? Подскажите тупому луддиту, чо.

это не хеллоу ворд и там нет очевидного места запуска

Любой процесс запускается.

Но даже если уже́ запущен, должен быть диалог «attach to process…»

Любой процесс запускается.

Угу, глубокая философская мысль.

Но даже если уже́ запущен, должен быть диалог «attach to process…»

Я уж думал и правда такое завезли в петон, но конечно же нет:

At this time, pdb does not have the ability to halt and begin debugging on a running program.

Кругом обман.