2009-10-07 17 views
6

De acuerdo con la documentación en Python getopt (creo) los campos de opciones deben comportarse como la función getopt(). Sin embargo, me parece que no puede permitir que los parámetros opcionales para mi código:¿Hay alguna forma de persuadir a getopt de Python para manejar los parámetros opcionales de las opciones?

#!/usr/bin/python 
import sys,getopt 

if __name__ == "__main__": 
    try: 
     opts, args = getopt.gnu_getopt(sys.argv[1:], "v::", ["verbose="]) 
    except getopt.GetoptError, err: 
     print str(err) 
     sys.exit(1) 

    for o,a in opts: 
     if o in ("-v", "--verbose"): 
      if a: 
       verbose=int(a) 
      else: 
       verbose=1 
      print "verbosity is %d" % (verbose) 

Resultados: en

$ ./testopt.py -v 
option -v requires argument 
$ ./testopt.py -v 1 
verbosity is 1 

Respuesta

8

getopt no admite parámetros opcionales. en el caso de la opción larga, puede hacer:

$ ./testopt.py --verbose= 

que dará como resultado un valor de cadena vacía.

Puede encontrar que el módulo argparse es más flexible.

5

Desafortunadamente, no hay manera. De optparse docs:

Normalmente, una opción dada toma un argumento o no. Mucha gente quiere una característica de "argumentos opcionales opcionales", lo que significa que algunas opciones tomarán un argumento si lo ven, y no lo harán si no lo hacen. Esto es un tanto controvertido porque hace que el análisis sea ambiguo: si "-a" toma un argumento opcional y "-b" es otra opción completamente diferente, ¿cómo interpretamos "-ab"? Debido a esta ambigüedad, optparse no admite esta característica.

EDIT: Uy, es decir para el módulo optparse no el módulo getopt, pero el razonamiento por qué ni módulo tiene "argumentos opcionales opción" es la misma para ambos.

+0

que es docs optparse;) – SilentGhost

+0

Sí, me di cuenta de que, caso clásico de "pestaña equivocada "síndrome". Sin embargo, sigo pensando que este razonamiento también es relativo para getopt. –

+0

Además, las opciones largas pueden tener argumentos opcionales sin ambigüedades; "--foo" vs. "--foo = arg". Python's no parece apoyar esto, que es muy pobre; un síntoma de reimplementar a medio camino algo desde cero ... –

0

Si está utilizando la versión 2.3 o posterior, puede probar el módulo optparse en su lugar, ya que es "más conveniente, flexible y potente ...", así como también más nuevo. Por desgracia, como Pynt respondió, no parece posible obtener exactamente lo que quieres.

+0

, excepto desde los documentos de 'optparser' ¡publicados por Pynt hace 45 minutos! – SilentGhost

+0

@SilentGhost: En mi lectura de la respuesta de Pynt, no veo nada que recomiende optparse sobre get_opt, que es a lo que me refería. Es cierto que no lo explicaba bien originalmente, pero he editado para hacerlo. – PTBNL

+0

optparse dice específicamente que no admite parámetros opcionales para las opciones. – stsquad

2

Usted puede hacer un parámetro opcional con getopt así:

import getopt 
import sys 

longopts, shortopts = getopt.getopt(sys.argv[1:], shortopts='', longopts=['env=']) 
argDict = dict(longopts) 

if argDict.has_key('--env') and argDict['--env'] == 'prod': 
    print "production" 
else: 
    print "sandbox" 

Uso: getopt

$ python scratch.py --env=prod 
production 

$ python scratch.py --env=dev 
sandbox 

$ python scratch.py 
sandbox 
0

de pitón en realidad debería apoyar argumentos opcionales, como getopt GNU exigiendo '=' usarse cuando se especifica un parámetro. Ahora puede simularlo bastante fácilmente, con esta restricción al cambiar implícitamente --option a --option =

I.E. puede especificar que --option requiere un argumento, y luego ajustar --option a --option = de la siguiente manera:

for i, opt in enumerate(sys.argv): 
    if opt == '--option': 
     sys.argv[i] = '--option=' 
    elif opt == '--': 
     break 
Cuestiones relacionadas