J'ai remarqué que la documentation de Python 2.7 comprend encore un autre module d'analyse syntaxique en ligne de commande. En plus de getopt y optparse nous avons maintenant argparse .
Pourquoi un énième module d'analyse syntaxique en ligne de commande a-t-il été créé ? Pourquoi devrais-je l'utiliser au lieu de optparse ? Y a-t-il de nouvelles fonctionnalités que je devrais connaître ?
A partir de python 2.7 , optparse est déprécié et, espérons-le, disparaîtra à l'avenir.
argparse est meilleur pour toutes les raisons énumérées sur sa page originale ( https://code.google.com/archive/p/argparse/ ) :
+ y /
De plus amples informations sont également disponibles dans PEP 389 qui est le véhicule par lequel argparse a été intégré dans la bibliothèque standard.
Une interface beaucoup plus simple pour les types personnalisés... mais une interface plus complexe dans l'ensemble. Je me demande vraiment pourquoi je suis passé à optparse, parce que roulement de tambour getopt va Restez sur . Ouaip, pas de dépréciation pour ce dinosaure. Sheeesh.
La mention de la "pureté" de optparse dans le PEP puis les arguments ultérieurs sur la complexité des ajouts donnent l'impression qu'il a été codé pour être aussi flexible que la roche (mal).
L'interface des sous-commandes est médiocre. La sortie par défaut n'est pas utile et il est difficile de la modifier.
Pourquoi devrais-je l'utiliser au lieu de optparse ? Y a-t-il de nouvelles fonctionnalités que je devrais-je connaître ?
La réponse de @Nicholas couvre bien cela, je pense, mais pas la question plus "méta" avec laquelle vous commencez :
Pourquoi une autre ligne de commande a été créé ?
C'est le dilemme numéro un lorsqu'un module utile est ajouté à la bibliothèque standard : que faire lorsqu'un moyen nettement meilleur, mais incompatible avec le passé, de fournir le même type de fonctionnalité émerge ?
Soit vous vous en tenez à l'ancienne méthode, qui a été dépassée (typiquement lorsque nous parlons de paquets compliqués : asyncore vs twisted, tkinter vs wx ou Qt, ...), soit vous vous retrouvez avec de multiples méthodes incompatibles pour faire la même chose (les analyseurs XML, à mon avis, en sont un meilleur exemple que les analyseurs en ligne de commande -- mais les email La comparaison entre le paquet et la myriade d'anciennes façons de traiter des problèmes similaires n'est pas très éloignée non plus;-).
Vous pouvez faire de menaçants grognements dans la documentation à propos des anciennes méthodes qui sont "dépréciées", mais (tant que vous avez besoin de conserver la compatibilité ascendante) vous ne pouvez pas vraiment les supprimer sans empêcher les grandes applications importantes de passer à des versions plus récentes de Python.
(Le deuxième dilemme, qui n'est pas directement lié à votre question, est résumé par le vieil adage "la bibliothèque standard est l'endroit où les bons paquets vont mourir"... avec des versions tous les ans et demi environ, des paquets qui ne sont pas très...), muy stable, no qui ont besoin de versions plus fréquentes que cela, peuvent en fait souffrir considérablement d'être "gelées" dans la bibliothèque standard... mais c'est vraiment un autre problème).
Certes, vous pouvez inclure argparse.py pour les installations de python antérieures à la version 2.7 et ne pas vous soucier des changements de rétrocompatibilité. C'est un élément supplémentaire à suivre, mais il est toujours maintenu en dehors de la bibliothèque standard à argparse.googlecode.com.
Argparse n'est sensiblement meilleur que pour certaines utilisations (de niche ?). Il n'est pas vraiment meilleur en termes absolus, c'est différents . Il peut faire des choses qu'optparse ne peut pas faire, mais il a aussi des régressions. Un exemple que je viens de rencontrer : optparse gère "--" par défaut (pas sûr qu'il ait fait ce que c'est supposé faire) alors qu'argparse n'en sait rien.
Pour ceux qui ont lu le commentaire ci-dessus tardivement, argparse vous permet de définir le préfixe et le nom, et la plupart des analyseurs sont écrits comme suit parser.add_argument('--long-opt', '-l',...) le "--" se manipule facilement, et comme vous le souhaitez.
La meilleure source de justification d'un ajout à Python serait son PEP : PEP 389 : argparse - Nouveau module d'analyse de la ligne de commande en particulier, la section intitulée, Pourquoi getopt et optparse ne sont-ils pas suffisants ?
Il y a aussi de nouveaux enfants dans le quartier !
Si vous souhaitez une comparaison plus approfondie, veuillez lire ce et vous pourriez finir par utiliser docopt o cliquez sur . Merci à Kyle Purdon !
Au début, j'étais aussi réticent que @fmark à passer de optparse à argparse, car :
Puis j'ai vu ce document, argparse surpasse optparse, surtout quand il s'agit de générer un message d'aide significatif : http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html
Et puis j'ai vu " argparse vs. optparse "par @Nicholas, disant que nous pouvons avoir argparse disponible dans python <2.7 (Yep, je ne le savais pas avant).
Maintenant, mes deux préoccupations sont bien prises en compte. J'ai écrit ceci en espérant que cela aidera d'autres personnes ayant un état d'esprit similaire.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
8 votes
Ou peut-être n'en utiliser aucun, car depuis 2012, Python dispose d'un outil facile, puissant et vraiment efficace. cool pour l'analyse des arguments appelé docopt. docopt.org
1 votes
Essayez de cliquer, c'est une enveloppe autour de optparse.