Почему использование argparse, а не optparse?
Я заметил, что документация Python 2.7 включает еще один модуль парсинга командной строки. В дополнение к getopt и optparse мы теперь имеем argparse.
Почему еще один модуль парсинга командной строки был создан? Почему я должен использовать его вместо optparse? Есть ли новые возможности, о которых я должен знать?
3 ответа
Начиная с python 2.7 , optparse устарел и, надеюсь, исчезнет в будущее.
argparse лучше по всем причинам, указанным на его исходной странице ( https://code.google.com / archive / p / argparse / ):
- обработка позиционных аргументов
- поддержка подкоманд
- разрешение альтернативных префиксов опций, таких как
+и/ - обработка ноль или более и один или несколько аргументов стиля
- , создающих более информативные сообщения об использовании
- , обеспечивающие гораздо более простой интерфейс для настраиваемых типов и действий
Дополнительная информация также находится в PEP 389 , с помощью которого argparse превратился в стандартную библиотеку.
Лучшим источником обоснования для добавления Python был бы его PEP: PEP 389: argparse - новый модуль синтаксического анализа командной строки , в частности, раздел, озаглавленный ] Почему getopt и optparse недостаточно?
Почему я должен использовать его вместо optparse? Их новые функции я
Ответ @Nicholas, я думаю, хорошо описывает это, но не тот более "мета" вопрос, с которого вы начинаете:
Почему есть еще одна командная строка был создан модуль синтаксического анализа?
Это дилемма номер один, когда какой-либо полезный модуль добавляется в стандартную библиотеку: что вы делаете, когда появляется существенно лучший, но обратно несовместимый способ предоставления такой же функциональности?
Либо вы придерживаетесь старого и, по общему признанию, превзойденного способа (обычно, когда мы говорим о сложных пакетах: asyncore vs twisted, tkinter vs wx или Qt, ...), либо вы получаете несколько несовместимых способов сделать то же самое ( Анализаторы XML, IMHO, являются даже лучшим примером этого, чем парсеры командной строки, но пакет email против бесчисленных старых способов решения подобных проблем тоже не так уж далек ;-).
Вы можете угрожающе ворчать в документации о том, что старые способы «устарели», но (до тех пор, пока вам нужно поддерживать обратную совместимость), вы не сможете их убрать, не остановив большие важные приложения от перехода на новые. Выпуски Python.
(Дилемма номер два, не имеющая прямого отношения к вашему вопросу, резюмируется в старой поговорке «стандартная библиотека - это место, где хорошие пакеты умирают» ...с выпусками каждые полтора года или около того, пакеты, которые не очень, очень стабильны, не нуждаются в выпусках чаще, чем это, могут существенно пострадать из-за "замораживания" в стандартной библиотеке ... но это совсем другая проблема).