C'est juste une préférence personnelle, et cela a à voir avec la disposition de vos modules python.
Disons que vous avez un module appelé erikutils
. Il y a deux façons dont il peut être un module, soit vous avez un fichier appelé erikutils.py sur votre sys.path
ou vous avez un répertoire appelé erikutils sur votre sys.path
avec un __init__.py
fichier vide à l'intérieur. Alors disons que vous avez un tas de modules appelés fileutils
, procutils
, parseutils
et vous voulez que ces sous- traiter les modules sous erikutils
. Vous créez donc des fichiers .py appelés fileutils.py , procutils.py et parseutils.py :
erikutils
__init__.py
fileutils.py
procutils.py
parseutils.py
Peut-être vous avez quelques fonctions qui juste ne appartiennent à la fileutils
, procutils
ou des parseutils
modules. Et disons que vous n'avez pas envie de créer un nouveau module appelé miscutils
. ET, vous aimeriez pouvoir appeler la fonction comme ceci:
erikutils.foo()
erikutils.bar()
plutôt que de faire
erikutils.miscutils.foo()
erikutils.miscutils.bar()
Donc, comme le erikutils
module est un répertoire, pas un fichier, nous devons définir ses fonctions à l'intérieur du __init__.py
fichier.
Dans django, le meilleur exemple auquel je puisse penser est django.db.models.fields
. TOUTES les classes de champ django * sont définies dans le __init__.py
fichier du répertoire django / db / models / fields . Je suppose qu'ils l'ont fait parce qu'ils ne voulaient pas tout entasser dans un modèle hypothétique django / db / models / fields.py , ils l'ont donc divisé en quelques sous-modules ( related.py , files.py , par exemple) et ils ont collé les définitions * de champ faites dans le module de champs lui-même (par conséquent, __init__.py
).