6.20.5.3 Altre motivazioni per estendere optparse

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:

  1. creare una classe derivata di OptionParser e sovrascrivere il metodo error().
  2. creare una classe derivata di Option e sovrascrivere il metodo take_action() -- dovrete fornire la vostra gestione dell'azione di ``help'', che non chiami sys.exit().

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.