Il problema con i singleton globali si riduce alla manutenzione del codice, all'architettura e alla sicurezza del thread.
In python, a meno che tu non stia usando Stackless Python, il GIL (Global Interpreter Lock: link ) aiuta a garantire thread- coerenza (al contrario di sicurezza ), quindi questo è meno un problema in Python rispetto ad altri linguaggi.
Tuttavia, ciò che devi chiedere quando stai guardando i singleton è perché?
Che cosa può un singleton globale darti che un metodo statico o una classe o una cache non possono? Che dire dell'utilizzo di un modello di progettazione di fabbrica per gestire correttamente la creazione di risorse DB?
Il problema con un singleton in uso è che un oggetto essere un singleton non è ovvio, mentre le classi o i metodi statici o le cache sono molto più evidenti nel modo in cui possono essere utilizzati e interagiti con.
Considera il seguente problema:
Decidi di usare un singleton in una libreria. Sei mesi dopo, trovi una user story in cui hai bisogno di multipli di quel singleton, ma hai dimenticato che è un singleton. Si tenta di creare copie, creare istanze nuove, ecc. Ecc. E continuare a correre in tutti questi strani difetti.
È qui che i singleton diventano un problema di manutenzione del codice e fino a quando non hai subito i costi e le frustrazioni causati da questo, è difficile capire perché i singleton sono un problema di odore di codice così grande.
Immagina anche peggio, che non hai il codice sorgente per la libreria, la documentazione è andata persa e non l'hai scritta. Come sapresti che un oggetto restituito era un singleton?
(Ho sperimentato quanto sopra in un lavoro precedentemente ... era ... divertente per alcune definizioni di divertimento.)