Комментарии 3
Проблема с использованием подпарсеров
Чтобы лучше разобраться в сути проблемы, следует рассмотреть самый базовый пример парсера, использующего дочерние элементы.
…
Проблема в том, что официальная документация гласит следующее
То есть за один запуск программы невозможно получить значения всех дочерних парсеров без танцев с бубнами.
Нет, это не «проблема». Ну т.е. это какая-то специфика бекенда. Но за весь длиннопост вы так ни разу и не написали (кроме скупого «Недавно мне потребовалось пересобрать N парсеров в один»), в чем же ваша *реальная* проблема была, зачем вам это. Вы решили, что вместо рефакторинга вашего кода лучше «хакнуть» официальный модуль, чтобы он вел себя так, как вам нужно? Ну, такое.
Нуачо. Зудело форкнуть - взял и форкнул. Такое обычно проходит со временем
Реальная проблема в том, что за 1 запуск программы, используя нативную библиотеку, нельзя взять и получить значения всех подпарсеров. На Stack эта проблема всплывала и раньше, но ее никто не решал. Поэтому - можно рекурсивно скармливать методу parse_known_args оставшиеся аргументы или решить проблему в корне
А нужно мне это для следующего:
Представим ситуацию, в которой каждый может добавлять "плагины" в программу. Каждый плагин может использовать парсинг аргументов, но при этом есть необходимость контролировать подобные действия. Это и вправду специфика бэкенда, как Вы и сказали, но в этом то и суть. Не решается глобальная проблема, но решается локальная и рассматривается, хоть и не во всех красках, что происходит за кулисами в этой либе.
Сказание о том, как я argparse препарировал