¿Por qué usar argparse en lugar de optparse?

Noté que la documentación de Python 2.7 incluye otro módulo de análisis de línea de comandos. Además de getopty optparseahora tenemos argparse.

¿Por qué se ha creado otro módulo de análisis de línea de comandos? ¿Por qué debería usarlo en lugar de optparse? ¿Hay nuevas características que debería conocer?

A partir de python 2.7, optparseestá en desuso y, con suerte, desaparecerá en el futuro.

argparsees mejor por todos los motivos enumerados en su página original ( https://code.google.com/archive/p/argparse/ ):

• manejo de argumentos posicionales
• subcomandos de apoyo
• permitiendo prefijos de opciones alternativas como +y/
• manejo de argumentos de estilo cero o más y uno o más
• produciendo mensajes de uso más informativos
• Proporciona una interfaz mucho más simple para tipos y acciones personalizados

También hay más información en PEP 389 , que es el vehículo por el que argparseingresó en la biblioteca estándar.

¿Por qué debería usarlo en lugar de optparse? ¿Son sus nuevas características las que debo conocer?

La respuesta de @ Nicholas cubre esto bien, creo, pero no la pregunta más "meta" con la que comienzas:

¿Por qué se ha creado otro módulo de análisis de línea de comandos?

Ese es el dilema número uno cuando se agrega un módulo útil a la biblioteca estándar: ¿qué hacer cuando surge una forma sustancialmente mejor, pero incompatible con versiones anteriores, de proporcionar el mismo tipo de funcionalidad?

O te quedas con la forma antigua y ciertamente superada (generalmente cuando hablamos de paquetes complicados: asyncore vs twisted, tkinter vs wx o Qt, ...) o terminas con múltiples formas incompatibles de hacer lo mismo (XML Los analizadores, en mi humilde opinión, son un ejemplo aún mejor de esto que los analizadores de línea de comandos, pero el email paquete frente a las innumerables formas antiguas de tratar problemas similares tampoco está demasiado lejos ;-).

Puede hacer gruñidos amenazantes en los documentos sobre las viejas formas de ser "obsoletas", pero (siempre que necesite mantener la compatibilidad con versiones anteriores) realmente no puede eliminarlas sin evitar que las aplicaciones grandes e importantes pasen a versiones más recientes de Python.

(El dilema número dos, no relacionado directamente con su pregunta, se resume en el viejo dicho "la biblioteca estándar es donde los buenos paquetes van a morir" ... con lanzamientos cada año y medio más o menos, paquetes que no son muy, muy estable, no necesita lanzamientos más a menudo que eso, en realidad puede sufrir sustancialmente al estar "congelado" en la biblioteca estándar ... pero, ese es realmente un problema diferente).

La mejor fuente de justificación para una adición de Python sería su PEP: PEP 389: argparse - Nuevo módulo de análisis de línea de comando , en particular, la sección titulada, ¿Por qué no son lo suficientemente getopt y optparse?

¡También hay nuevos niños en la cuadra!

• Además del ya mencionado optparse en desuso . [NO UTILICE]
• argparse se mencionó , que es una solución para las personas que no desean incluir libs externas.
• docopt es una biblioteca externa que vale la pena ver, que utiliza una cadena de documentación como analizador para su entrada.
• click también es lib externo y usa decoradores para definir argumentos. (Mi fuente recomienda: ¿Por qué hacer clic? )
• python-inquirer Para herramientas enfocadas en la selección y basadas en Inquirer.js ( repo )

Si necesita una comparación más detallada, lea esto y puede terminar usando docopt o haga clic . Gracias a Kyle Purdon!

Al principio era tan reacio como @fmark a cambiar de optparse a argparse, porque:

1. Pensé que la diferencia no era tan grande.
2. Algunos VPS todavía proporcionan Python 2.6 por defecto.

Luego vi este documento, argparse supera a optparse, especialmente cuando se habla de generar un mensaje de ayuda significativo: http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html

Y luego vi " argparse vs. optparse " de @Nicholas, diciendo que podemos tener argparse disponible en python <2.7 (Sí, no lo sabía antes).

Ahora mis dos preocupaciones están bien atendidas. Escribí esto esperando que ayude a otros con una mentalidad similar.