Il modo Pythonic di organizzare moduli e pacchetti

Question

Vengo da uno sfondo in cui di solito creo un file per classe. Organizzo anche corsi comuni sotto directory. Questa pratica è intuitiva per me ed è stata dimostrata efficace in C ++, PHP, JavaSript, ecc.

Sto riscontrando problemi nel portare questa metafora in Python: i file non sono più solo file, ma sono moduli formali. Non sembra giusto avere solo una classe in un modulo --- la maggior parte delle classi sono inutili da sole. Se ho una automobile.py e una Automobile , sembra sciocco fare sempre riferimento anche a automobile.Automobile .

Ma, allo stesso tempo, non sembra giusto gettare un sacco di codice in un file e chiamarlo un giorno. Ovviamente, un'applicazione molto complessa dovrebbe avere più di 5 file.

Qual è il modo corretto --- o pitonico ---? (O se non esiste un modo corretto, qual è il tuo modo preferito e perché?) Quanto codice dovrei lanciare in un modulo Python?

Answer 1

Pensa in termini di "unità logica di imballaggio" - che può essere una singola classe, ma più spesso sarà un insieme di classi che cooperano strettamente. Le classi (o funzioni a livello di modulo - non " eseguono Java in Python " utilizzando sempre metodi statici quando le funzioni a livello di modulo sono disponibili anche come scelta! -) possono essere raggruppate in base a questo criterio. Fondamentalmente, se anche la maggior parte degli utenti di A ha bisogno di B e viceversa, A e B dovrebbero probabilmente trovarsi nello stesso modulo; ma se molti utenti avranno bisogno solo di uno di essi e non dell'altro, allora dovrebbero probabilmente trovarsi in moduli distinti (forse nello stesso pacchetto, cioè una directory con un file __init__.py ).

La libreria standard di Python, sebbene lungi dall'essere perfetta, tende a riflettere (per lo più) buone pratiche ragionevolmente - quindi puoi principalmente imparare da essa con l'esempio. Ad esempio, il modulo threading ovviamente definisce una classe Thread ... ma contiene anche le classi primitive di sincronizzazione come blocchi, eventi, condizioni e semafori e un classe di eccezioni che può essere generata da operazioni di threading (e poche altre cose). È al limite superiore di dimensioni ragionevoli (800 righe inclusi spazi bianchi e docstring) e alcune funzionalità cruciali relative al thread come Queue sono state collocate in un modulo separato, tuttavia è un buon esempio di quale massima funzionalità abbia ancora senso per impacchettare in un singolo modulo.

Answer 2

Se vuoi restare fedele al tuo sistema a una classe per file (che è logico, non fraintendermi), potresti fare qualcosa del genere per evitare di fare riferimento a automobile.Automobile :

from automobile import Automobile
car = Automobile()

Tuttavia, come indicato da Cobbal, più di una classe per file è abbastanza comune in Python. Ad ogni modo, finché scegli un sistema sensibile e lo usi in modo coerente, non penso che nessun utente Python si arrabbierà con te :).

Answer 3

Se si proviene da un punto di vista c ++, è possibile visualizzare i moduli Python affini a un .so o .dll. Sì, sembrano file sorgente, perché python è scriptato, ma in realtà sono librerie caricabili con funzionalità specifiche.

Un'altra metafora che può aiutarti è che potresti sembrare i moduli Python come spazi dei nomi.

Answer 4

In un progetto di medie dimensioni, mi sono trovato con diverse serie di classi strettamente correlate. Molti di questi set sono ora raggruppati in file; ad esempio, le classi di rete di basso livello sono tutte in un singolo modulo network . Tuttavia, alcune delle classi più grandi sono state suddivise nel proprio file.

Forse il modo migliore per iniziare quel percorso da una cronologia di una classe per file è quello di prendere le classi che normalmente inseriresti nella stessa directory e invece di mantenerle nello stesso file. Se il file inizia a sembrare troppo grande, dividerlo.

Answer 5

Come vaga linea guida: più di 1 classe per file è la norma per Python

inoltre, vedi Quante classi Python dovrei mettere in un file?