Come lavorare elegantemente con molte funzioni di stampa?

Penso che dipenda da quanto tu possa essere riusabile il tuo codice. Nel modo più semplice, puoi semplicemente sostituire tutte le dichiarazioni di stampa che hai con una tua funzione che risolve il problema. Potresti implementare un sistema di registrazione con diversi livelli di registro, ma sono sicuro che ce ne sia già uno.

Una delle cose utili del wrapping della stampa è che puoi anche disattivare certi messaggi se lo desideri.

Non sei sicuro che questo sia importante per te, ma la semantica della stampa differisce tra il Python più recente e quello che avevamo prima, quindi scrivere il tuo wrapper potrebbe rendere la transizione molto più semplice.

Posso suggerire di dare un'occhiata all'architettura in stile Model / View / Controller.

In questo modo è possibile scrivere un'implementazione di modello e controllore che esegue ciò che l'applicazione deve eseguire e quindi è possibile scrivere due viste separate. Una vista della GUI e una vista della console.

Dai un'occhiata al pacchetto curses per python come modo di fare un'interfaccia GUI su un'app console (se appropriata), oppure puoi usare un'interfaccia in stile linea di comando per definire uno script definito di azioni sui dati se lo strumento cmd è progettato per essere non interattivo nel suo utilizzo.

Lasciare la registrazione sparsi nel tuo codice e provare a fare la cosa giusta in ogni istanza, è probabilmente poco pratico.

Ci sono un paio di approcci popolari, che si differenziano principalmente per la struttura dei dati interni / intermedi.

1. Lo schema Model-View-Controller potrebbe suddividere l'applicazione in circa questi componenti:

   1. Model è lo stato e la logica dell'applicazione interna: non dovrebbe stampare nulla (tranne forse errori fatali, to stderr), ma dovrebbe essere in grado di inviare eventi chiamando metodi sull'oggetto
   2. View sarebbe una classe base astratta in un linguaggio tipizzato staticamente: in Python non ne hai affatto bisogno, tranne come idea dell'interfaccia chiamata dal Modello e implementata da:
   3. TerminalView, che stamperà qualcosa di adatto al terminale quando Model chiama un metodo
   4. GraphicalView, che visualizzerà le informazioni graficamente invece

   Un possibile problema con questo approccio è che devi fornire un formato un po ' per i dati passati dal modello all'oggetto View, ed è impossibile per me dire quanto sia complesso la tua applicazione, quanto deve essere flessibile, ecc.

2. Lo schema porcellana / cromo, usato da git:

   questo mantiene l'idea di un back-end (Modello) che eviti di pensare a come presentare informazioni, ma si tratta di un testo analizzabile dalla macchina.

   Potresti comunque volere un front-end per trasformare l'output di testo leggibile dalla macchina in un output di testo leggibile dall'utente (così come il nuovo front-end della GUI per visualizzarlo graficamente), nel qual caso sono esattamente equivalenti a i due tipi di vista concreti descritti in precedenza.

   Se puoi formattare l'output di testo che è facilmente leggibile dalla macchina e facilmente leggibile, puoi saltare il front-end del terminale e rendere la GUI un wrapper attorno al terminale esistente applicazione.

Tieni presente che ho omesso interamente la parte Controller di MVC, perché non è chiaro se tu abbia effettivamente bisogno di interazione e feedback, o semplicemente di output.

Dovresti dividere l'interfaccia utente e la logica, questo è sicuro.

Ci sono più schemi per questo, uno di questi è MVC che @Ptolemy ha già menzionato. Ce ne sono più di loro. MVC potrebbe sembrare troppo difficile da comprendere (un po 'scherzosamente, nessuno sa veramente come fare MVC, ma è soprattutto perché ha molti gusti distinti durante la sua lunga storia), ma anche se si fa un sistema più ingenuo all'inizio , va bene.

L'obiettivo che dovresti avere è dividere il più possibile il processo di visualizzazione dei dati dalla logica dell'applicazione. Se non vuoi studiare MVC e tutte le sue varianti (MVP, MVVM), puoi fare la semplice lavagna e lasciare che sia il modello (la parte logica) che la vista (la parte di stampa) accedano solo alla lavagna (la lavagna è dati astrazione in cui i dati vengono inseriti in un negozio ("lavagna") e più pezzi di software ("agenti") lo stanno osservando per le modifiche, ogni agente interessato solo al proprio sottoinsieme, e quindi prende i dati dalla lavagna, fa qualche azione e riporta il risultato). Il tipo di dati della lavagna è buono per mantenere separate le diverse parti del SW, ma comunque fornire loro un modo controllato per comunicare.

Ma ci sono molti modi per ottenere la divisione.