Argparse группы в

Question

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

Метод 1:

./filter.py filename --start_regex "^FOO" --end_regex "BAR$" --contains "XXX" --bunch_of_common_options 

Метод 2:

./filter.py filename --type "FOO_BAR_XXX" --bunch_of_common_options

Логически оба делают точно так же, поскольку в есть dict, который переводит тип «FOO_BAR_XXX» из метода 2 в соответствующие варианты для метода 1.

Я хочу, чтобы указать, что, учитывая:

GroupA = (--start_regex, --end_regex --contains)

GroupB = (--type)

GroupA и GroupB являются:

1. взаимоисключающими, и
2. GroupA должны иметь по крайней мере start_regex определено

Теперь я знаю mutually_exclusive_group функциональности, но он работает только на отдельных аргументов (не группы вариантов), и sub-commands, но, похоже, я бы есть какой-то вариант отправки после prog.py, как «мерзавца клон --help», или «мерзавец нажимной --help» (this пост доказывает, что)

Обратите внимание, что это не так элегантно сказать:

./filter.py with_type filename --type TYPE1 
./filter.py without_type filename --start_regex "^FOO" --end_regex "BAR$" --contains "XXX" 

Или я что-то упускаю?

Answer 1

groups не влияют на синтаксический анализ каким-либо значительным образом. Обычный argument groups просто влияет на форматирование help (вы можете определить такие группы именно для этой цели). Взаимоисключающие группы влияют на форматирование использования (но вы можете сделать свою собственную пользовательскую строку использования) и выдать сообщение об ошибке, если они нарушены. Но вы можете так же хорошо провести такой тест после parse_args и даже использовать argparse.error для получения отформатированного сообщения об ошибке. После этого вы также можете выполнить «взаимоисключающие» тесты.

Существует «проблема с python», которая исследует включение аргумента в более чем одну взаимоисключающую группу. В этом случае вы можете сделать 3 группы, по одному для каждого из аргументов группы А, и поместить в них аргумент --type. Это дополнение было легким; форматирование значимого usage заняло больше внимания. См. Связанную проблему SO.

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

---

несколько других вариантов:

Написать пользовательские действия или действия. Действие 'regex_end', например, может быть объектом, если пространство имен еще не имеет значения 'regex_begin' или имеет значение типа. Действие типа может проверять его формат и объект, если один из них уже установлен.Но вы бы делали те же тесты в случае post-parse_args.

A '--regex', nargs=3, metavar=('begin','end','content') аргумент. Это может быть взаимоисключающим с --type. Вы могли бы даже назначить группу по мере необходимости.