Aggiunta di codice a __init__.py

Sto dando un'occhiata a come funziona il sistema modello in django e ho notato qualcosa che non capisco.

So che crei un __init__.pyfile vuoto per specificare che la directory corrente è un pacchetto. E che puoi impostare qualche variabile in __init__.pymodo che import * funzioni correttamente.

Ma django aggiunge un gruppo di istruzioni from ... import ... e definisce un gruppo di classi in __init__.py. Perché? Questo non fa solo sembrare le cose disordinate? C'è un motivo per cui richiede questo codice __init__.py?

Tutte le importazioni in __init__.pyvengono rese disponibili quando si importa il pacchetto (directory) che lo contiene.

Esempio:

./dir/__init__.py:

import something

./test.py:

import dir
# can now use dir.something

EDIT: ho dimenticato di menzionare, il codice __init__.pyviene eseguito la prima volta che importi un modulo da quella directory. Quindi è normalmente un buon posto per inserire qualsiasi codice di inizializzazione a livello di pacchetto.

EDIT2: dgrant ha sottolineato una possibile confusione nel mio esempio. In __init__.py import somethingpuò importare qualsiasi modulo, non necessario dal pacchetto. Ad esempio, possiamo sostituirlo con import datetime, quindi nel nostro livello superiore funzioneranno test.pyentrambi questi snippet:

import dir
print dir.datetime.datetime.now()

e

import dir.some_module_in_dir
print dir.datetime.datetime.now()

La linea di fondo è: tutti i nomi assegnati in __init__.py, siano essi moduli, funzioni o classi importati, sono automaticamente disponibili nello spazio dei nomi del pacchetto ogni volta che si importa il pacchetto o un modulo nel pacchetto.

È solo una preferenza personale e ha a che fare con il layout dei tuoi moduli Python.

Supponiamo che tu abbia un modulo chiamato erikutils. Ci sono due modi in cui può essere un modulo, o hai un file chiamato erikutils.py sul tuo sys.patho hai una directory chiamata erikutils sul tuo sys.pathcon un __init__.pyfile vuoto al suo interno. Quindi diciamo che si dispone di un gruppo di moduli chiamati fileutils, procutils, parseutilse si desidera quelle da sottomoduli sotto erikutils. Quindi crei alcuni file .py chiamati fileutils.py , procutils.py e parseutils.py :

erikutils
  __init__.py
  fileutils.py
  procutils.py
  parseutils.py

Forse avete un paio di funzioni che semplicemente non appartengono nei fileutils, procutilso parseutilsmoduli. E diciamo che non hai voglia di creare un nuovo modulo chiamato miscutils. E, vorresti poter chiamare la funzione in questo modo:

erikutils.foo()
erikutils.bar()

piuttosto che fare

erikutils.miscutils.foo()
erikutils.miscutils.bar()

Quindi, poiché il erikutilsmodulo è una directory, non un file, dobbiamo definire le sue funzioni all'interno del __init__.pyfile.

In Django, il miglior esempio a cui riesco a pensare è django.db.models.fields. TUTTE le classi django * Field sono definite nel __init__.pyfile nella directory django / db / models / fields . Immagino che lo abbiano fatto perché non volevano stipare tutto in un ipotetico modello django / db / models / fields.py , quindi lo hanno diviso in alcuni sottomoduli ( related.py , files.py , per esempio) e hanno bloccato le definizioni * Field fatte nel modulo dei campi stesso (quindi, __init__.py).

L'utilizzo del __init__.pyfile consente di rendere invisibile dall'esterno la struttura interna del pacchetto. Se la struttura interna cambia (ad esempio perché dividi un modulo fat in due) devi solo modificare il __init__.pyfile, ma non il codice che dipende dal pacchetto. Puoi anche rendere invisibili parti del tuo pacchetto, ad esempio se non sono pronte per l'uso generale.

Nota che puoi usare il delcomando, quindi un tipico __init__.pypotrebbe essere simile a questo:

from somemodule import some_function1, some_function2, SomeObject

del somemodule

Ora se decidi di dividere somemoduleil nuovo __init__.pypotrebbe essere:

from somemodule1 import some_function1, some_function2
from somemodule2 import SomeObject

del somemodule1
del somemodule2

Dall'esterno la confezione sembra ancora esattamente come prima.