Python - opzioni di configurazione, come inserire / gestire?

Question

Quando l'applicazione accetta alcuni (~ 5) parametri di configurazione e l'applicazione procede per essere utilizzato da utenti non tecnologici (ad es. KISS ), come gestite normalmente la lettura opzioni di configurazione, quindi passando i parametri tra oggetti / funzioni (moduli multipli)?

Esempi di opzioni: directory di input / output / nomi file, livello di dettaglio.

In genere utilizzo optparse (Python) e passo le opzioni / i parametri come argomenti; ma mi chiedo se è più comune usare un testo di configurazione file che viene letto direttamente dagli oggetti di tutti i moduli (ma non è questo come avere variabili "globali"? E senza che nessuno "possieda" lo stato?).

Un altro problema tipico è il test unitario; se voglio provare l'unità ciascuno modulo singolo in modo indipendente, un modulo particolare può richiedere solo 1 delle 5 opzioni di configurazione; come fai di solito a disaccoppiare l'individuo moduli / oggetti dal resto dell'applicazione, e tuttavia lo consentono ancora accetta 1 o 2 parametri richiesti (il framework dell'unità test in qualche modo invocare o assumere la funzionalità di configurazione)?

La mia ipotesi è che non esiste un modo corretto unico per farlo, ma lo farebbe essere interessante leggere su vari approcci o modelli ben noti.

Answer 1

"Counts answer"
Please update these counts and feel free to add/modify.

Do you usually read config options via:
- command-line/gui options : 1
- a config text file       : 0


How do multiple modules/objects have access to these options?
- they receive them from the caller as an argument: 1
- read them directly from the config text file:     0


When doing unit-testing of a single module (NOT the "main" module)
and the module uses one option, e.g. input filename:
- unit-test framework provides own "simplified" config functionality: 0
- unit-test framework invokes main app's config functionality:        1


Do you use:
- optparse:  1
- getopt:    0
- others?


Please list any config management "design pattern" 
(usable in Python) and add a count if you use it - thanks.
- 
-

Answer 2

Di solito leggi le opzioni di configurazione tramite: - Opzioni da riga di comando / gui - un file di testo di configurazione

Entrambi. Usiamo settings.py e logging.ini di Django. Utilizziamo anche opzioni e argomenti della riga di comando per le opzioni che cambiano più frequentemente.

In che modo più moduli / oggetti hanno accesso a queste opzioni?

• settings.py; logging.ini - non posso dire.
• Le nostre opzioni sono private per il programma principale e utilizzate per creare
  argomenti per funzioni o inizializzatori di oggetti.

[La condivisione delle opzioni optparse è un grande dolore al collo e inutilmente lega molte cose in un pasticcio non verificabile.]

Quando si esegue il test unitario di un singolo modulo (NON il modulo "principale"): (ad es. opzione di lettura che specifica il nome file di input)

[Non riesco ad analizzare la domanda. Presumo che questo sia " come testate quando ci sono opzioni? & Quot;]

La risposta è: noi no. Poiché solo il metodo principale analizza le opzioni della riga di comando, nessun altro modulo, funzione o classe ha idea delle opzioni della riga di comando. Non esiste questo modulo "richiede 1 delle 5 opzioni di configurazione" Le classi (o le funzioni) del modulo hanno argomenti ordinari e basta.

Utilizziamo solo optparse .