<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Carlos Catucci:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">E un decorator che a seconda che sia True o False una global DEBUGGER no?<br></div><div class="gmail_extra">Comunque io mi riferivo all'uso di un controllo momentaneo, risolvo il problema e lo sego, non li lascio proliferare.<br></div><span class=""><div class="gmail_extra"></div></span></blockquote></div><br><div><div class="gmail_signature"><div>ok, allora ci dobbiamo mettere d'accordo sulla parola debug.</div><div>perché se li seghi allora per me si chiama sviluppo.</div><div>mentre Il debug lo associo all'attività di ricerca di un errore, solitamente il codice è in produzione.</div><div><br></div><div>Cmq tieni conto che creare stringhe al volo con parametri arbitrari, e stamparle sullo standard output è una operazione onerosa per la macchina (cpu e disk). Chiaramente con alti carichi. Se poi l'applicativo è multithread, debbuggarla tramite file di log diventa oltre che oneroso parecchio complicato. Se è multiprocesso peggio, i processi concorrenti che scrivono su un unico file di log usano i meccanismi di lock del sistema operativo per scrivere sul file, bloccandosi a vicenda.</div><div><br></div><div>Almeno il modulo logging a differenza di print non crea alcuna stringa con i parametri che gli passi a meno che il debug non sia effettivamente abilitato e quindi non scrive e/o blocca nulla. Fa solo una chiamata appendendo una funzione con riferimenti a stringhe costanti e parametri nello stack. Il costo c'è ma è ben poca cosa.</div><div><br></div><div><br></div></div></div>
</div></div>