Позиционный arg начинается с дефиса в argparse [duplicate]

Этот вопрос подробно обсуждается в http://bugs.python.org/issue9334 . Большая часть активности была в 2011 году. Я добавил патч в прошлом году, но есть довольно отставание от патчей argparse.

Проблема заключается в потенциальной двусмысленности в строке, такой как '--env' или "-s WHATEVER -e COOL STUFF", когда она следует за опцией, которая принимает аргумент.

optparse выполняет простой анализ слева направо. Первый --env - это флаг опции, который принимает один аргумент, поэтому он потребляет следующий, независимо от того, как он выглядит. argparse, с другой стороны, дважды проходит строки. Сначала он классифицирует их как «O» или «A» (флаг или аргумент опций). Во втором цикле он потребляет их, используя сопоставление типа re, подходящее для обработки значений переменной nargs. В этом случае мы видим, что у нас есть OO, два флага и никаких аргументов.

Решение при использовании argparse состоит в том, чтобы убедиться, что строка аргумента не будет путаться для флажка параметра. Возможности, которые были показаны здесь (и в проблеме с ошибкой), включают в себя:

--env="--env"  # clearly defines the argument.

--env " --env"  # other non - character
--env "--env "  # space after

--env "--env one two"  # but not '--env "-env one two"'

Сам по себе '--env' выглядит как флаг (даже при цитировании, см. sys.argv), но затем следуют другие строк это не так. Но "-env one two" имеет проблемы, поскольку он может быть проанализирован как ['-e','nv one two'], флаг `-e ', за которым следует строка (или даже больше параметров).

-- и nargs=argparse.PARSER также могут используется для принудительного [[22]) для просмотра всех последующих строк в качестве аргументов. Но они работают только в конце списков аргументов.

В вопросе 9334 есть исправление, добавляющее режим args_default_to_positional=True. В этом режиме анализатор только классифицирует строки как флаги опций, если он может четко соответствовать им с определенными аргументами. Таким образом, «-one» в «--env -one» будет классифицирован как аргумент. Но второй '--env' в '--env --env' по-прежнему будет классифицироваться как флаг опции.

Расширение в соответствующем случае в

Использование аргумента argparse с аргументами, начинающимися с тире («-»)

parser = argparse.ArgumentParser(prog="PROG")
parser.add_argument("-f", "--force", default=False, action="store_true")
parser.add_argument("-e", "--extra")
args = parser.parse_args()
print(args)

производит

1513:~/mypy$ python3 stack16174992.py --extra "--foo one"
Namespace(extra='--foo one', force=False)
1513:~/mypy$ python3 stack16174992.py --extra "-foo one"
usage: PROG [-h] [-f] [-e EXTRA]
PROG: error: argument -e/--extra: expected one argument
1513:~/mypy$ python3 stack16174992.py --extra "-bar one"
Namespace(extra='-bar one', force=False)
1514:~/mypy$ python3 stack16174992.py -fe one
Namespace(extra='one', force=True)

Случай «-foo one» терпит неудачу, потому что -foo интерпретируется как флаг -f плюс неуказанные дополнения. Это то же самое действие, которое позволяет -fe интерпретироваться как ['-f','-e'].

Если я изменю nargs на REMAINDER (не PARSER), все после -e интерпретируется как аргументы для этого флага:

parser.add_argument("-e", "--extra", nargs=argparse.REMAINDER)

Все дела работают. Обратите внимание, что это список. И кавычки не нужны:

1518:~/mypy$ python3 stack16174992.py --extra "--foo one"
Namespace(extra=['--foo one'], force=False)
1519:~/mypy$ python3 stack16174992.py --extra "-foo one"
Namespace(extra=['-foo one'], force=False)
1519:~/mypy$ python3 stack16174992.py --extra "-bar one"
Namespace(extra=['-bar one'], force=False)
1519:~/mypy$ python3 stack16174992.py -fe one
Namespace(extra=['one'], force=True)
1520:~/mypy$ python3 stack16174992.py --extra --foo one
Namespace(extra=['--foo', 'one'], force=False)
1521:~/mypy$ python3 stack16174992.py --extra -foo one
Namespace(extra=['-foo', 'one'], force=False)

argparse.REMAINDER похож на '*', за исключением того, что он принимает все, что следует, независимо от того, выглядит он как флаг или нет. argparse.PARSER больше похож на «+», поскольку он сначала ожидает такой же positional аргумент. Это nargs, который использует subparsers.

Это использование REMAINDER задокументировано, https://docs.python.org/3/library/argparse.html#nargs

Обновленный ответ:

Вы можете поместить знак равенства, когда вы его назовете:

python Application.py -env="-env"

Оригинальный ответ:

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

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

python Application.py -e "+s WHATEVER +e COOL STUFF"

, а затем вы меняете «+» на «-» в пост-обработке перед тем, как перейти к вашему подпроцессу.