Я заметил, что в документации Python 2.7 имеется еще один модуль синтаксического анализа командной строки. В дополнение к getopt и optparse теперь мы имеем argparse.
Почему был создан еще один модуль синтаксического анализа командной строки? Почему я должен использовать его вместо optparse? Есть ли новые функции, о которых я должен знать?
Как и в случае с python 2.7, optparse устарел и, надеюсь, уйдет в будущем.
argparse лучше по всем причинам, указанным на его исходной странице (https://code.google.com/archive/p/argparse/):
+ и /Дополнительная информация также находится в PEP 389, который является транспортным средством, с помощью которого argparse попал в стандартную библиотеку.
Почему я должен использовать его вместо optparse? Являются ли их новые возможности я должен знать?
@Николас отвечает на это хорошо, я думаю, но не более "мета" вопрос, который вы начинаете с:
Почему еще одна команда был создан модуль синтаксического анализа?
Что дилемма номер один, когда какой-либо полезный модуль добавляется в стандартную библиотеку: что вы делаете, когда появляется существенно лучший, но обратный-несовместимый способ обеспечения такой же функциональности?
Либо вы придерживаетесь старого и, по общему признанию, превзойденного пути (обычно, когда мы говорим о сложных пакетах: asyncore vs twisted, tkinter vs wx или Qt,...), или вы получаете несколько несовместимых способов сделать то же самое вещь (синтаксические анализаторы XML, IMHO, являются еще лучшим примером этого, чем синтаксические анализаторы командной строки), но пакет email и множество старых способов решения подобных проблем не слишком далеко: -).
Вы можете угрожать ворчаниям в документах о том, что старые способы "устарели", но (пока вам нужно поддерживать обратную совместимость) вы не можете их отнять, не останавливая больших важных приложений от перехода на более новые Выпуски Python.
(Дилемма номер два, не связанная напрямую с вашим вопросом, обобщается в старой поговорке "стандартная библиотека, где хорошие пакеты идут умирать"... с выпуском каждые полтора года или около того, пакеты, t не, нуждающийся в выпуске, чаще всего может существенно пострадать, будучи "замороженным" в стандартной библиотеке... но это действительно другой вопрос).
Лучшим источником для обоснования добавления Python будет его PEP: PEP 389: argparse - новый модуль анализа командной строки, в частности, раздел, озаглавленный Почему недостаточно getopt и optparse?
На блоке тоже есть новые детишки!
Если вам нужно более глубокое сравнение, прочитайте это, и вы можете использовать docopt или click. Благодаря Кайлу Пурдону!
Сначала я был так же неохотно, как @fmark переключиться с optparse на argparse, потому что:
Затем я увидел этот документ, argparse превосходит optparse, особенно когда речь идет о создании содержательного справочного сообщения: http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html
И затем я увидел " argparse vs. optparse от @Nicholas, говоря, что мы можем иметь argparse, доступный в python < 2.7 (Yep, Я этого раньше не знал.)
Теперь мои две проблемы хорошо решены. Я написал это в надежде, что это поможет другим с похожим мышлением.
Существует раздел в PEP 389, который напрямую решает этот вопрос.
Я лично предпочитаю optparse, а не argparse, потому что
argparse заключается в том, что он имеет некоторые проблемные поведения, которые делают обработку произвольных интерфейсов командной строки.
У argparse есть встроенное магическое поведение, чтобы угадать, является ли что-то аргументом или опцией. Это становится проблемой при работе с неполными командами, поскольку его невозможно узнать, не имея полного понимания командной строки, как будет вести себя парсер.
В настоящее время argparse не поддерживает отключение вкрапленных аргументов.
Оба работают отлично для основных приложений командной строки.