Зачем использовать argparse, а не optparse?

Я заметил, что документация 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.

(Дилемма номер два, напрямую не связанная с вашим вопросом, резюмируется в старой поговорке «стандартная библиотека - это то место, куда умирают хорошие пакеты» ... с выпусками раз в полтора года или около того, пакеты не очень, очень стабильный, не нуждающийся в выпусках чаще, чем он, может существенно пострадать, будучи "замороженным" в стандартной библиотеке ... но это действительно другая проблема).

Наилучшим источником для обоснования добавления Python является его PEP: PEP 389: argparse - новый модуль синтаксического анализа командной строки , в частности раздел, озаглавленный « Почему недостаточно getopt и optparse?»

Есть также новые дети на блоке!

• Помимо уже упомянутого устаревшего optparse . [НЕ ИСПОЛЬЗУЙ]
• Был также упомянут argparse , который является решением для людей, не желающих включать внешние библиотеки.
• docopt - это внешняя библиотека , на которую стоит обратить внимание, которая использует строку документации в качестве парсера для вашего ввода.
• click также является внешней библиотекой и использует декораторы для определения аргументов. (Мой источник рекомендует: зачем кликать )
• python-inquirer Для выбора целевых инструментов и на основе Inquirer.js ( репо )

Если вам нужно более глубокое сравнение, прочитайте это, и вы можете использовать docopt или click . Спасибо Кайлу Пурдону!

Сначала я так же неохотно, как @fmark, переключался с optparse на argparse, потому что:

1. Я думал, что разница не так уж велика.
2. Некоторые VPS по-прежнему предоставляют Python 2.6 по умолчанию.

Затем я увидел этот документ, argparse превосходит optparse, особенно когда речь идет о создании значимого справочного сообщения: http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html

А потом я увидел « argparse vs. optparse » от @Nicholas, который сказал, что argparse может быть доступен на python <2.7 (Да, я не знал этого раньше).

Теперь мои две проблемы хорошо решены. Я написал это, надеясь, что это поможет другим с подобным мышлением.