Aggiungere nuovi tipi e nuove azioni sono le principali, ovvie ragioni per cui possiate voler estendere optparse. Si può pensare ad almeno due motivi.
Il primo metodo, quello semplice: OptionParser cerca di essere d'aiuto chiamando sys.exit() quando necessario, per esempio quando si verifica un errore sulla riga di comando o quando l'utente richiama l'help. Nel primo caso, il metodo tradizionale di lasciare che lo script si blocchi con un traceback è inaccettabile; questo farà pensare agli utenti che lo script abbia un difetto quando invece causano un errore da riga di comando. Nel secondo caso, non c'è molto da fare dopo che è stato stampato il messaggio di aiuto.
Se questo comportamento non vi soddisfa, non dovrebbe essere troppo difficile ``correggerlo''. Dovrete:
Il secondo metodo, molto più complesso, è quello di sovrascrivere la
sintassi della riga di comando implementata da optparse. In
questo caso, dovrete abbandonare a se stessa l'intera struttura delle
azioni sulle opzioni e sui tipi, riscrivendo il codice che processa
sys.argv
. Dovrete comunque derivare una classe da
OptionParser; in funzione di quanto sarete radicali nella
riscrittura, probabilmente dovrete sovrascrivere uno o tutti tra i
metodi parse_args(), _process_long_opt() e
_process_short_opts().
Entrambi questi approcci vengono lasciati come un esercizio per il lettore. Non ho provato a implementarli personalmente, in quanto mi trovo già bene con il comportamento predefinito di optparse (naturalmente).
Buon Hacking, e non dimenticate: Usa il Sorgente, Luke.
Vedete Circa questo documento... per informazioni su modifiche e suggerimenti.