Les modules et packages en Python sont des "espaces de noms"

Motivation pour écrire cet article

• Il est difficile d'intégrer la philosophie "1 fichier de classe 1" dans d'autres langages sans comprendre le système d'empaquetage de Python. ―― Je vois souvent l'article d'introduction "Vous pouvez écrire comme ceci lorsque vous utilisez des modules et des packages", mais il est difficile de voir la discussion sur la façon dont il est censé être utilisé (surtout qu'est-ce que __init __. Py?" ne sait pas) «Je ne veux pas le forcer, n'est-ce pas comme ça comme base? je veux parler

Je vous serais reconnaissant de bien vouloir me faire savoir s’il existe quelque chose comme «Ecrivez correctement cet article ou document».

Inconvénients de la séparation des fichiers par classe

Dans les langages tels que Java et C # qui sont contraints par l'orientation objet, je pense qu'il est habituel d'écrire une classe publique par fichier.

Mais en python, ~ .py sont tous des modules, et les modules sont un ensemble de fonctionnalités qu'ils fournissent. Je pense que le module peut avoir plusieurs classes.

Par exemple, dans les models.py de Django (le module par défaut qui implémente la classe d'entité ORM), c'est une image d'écriture de toutes les classes d'entités dans une ligne.

models.py

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

Extrait de "Créer votre première application Django, partie 2"

Il peut être rare dans la pratique que ce nombre de lignes corresponde, mais est-il si avantageux de séparer une classe d'au plus quelques lignes dans un fichier séparé? Bien sûr, si la langue change, le sens commun change également. Je pense que c'est différent de traiter 1 fichier de classe 1 comme spécifié en python.

La principale raison pour laquelle je ressens cela est que cela affecte la façon dont j'écris «import».

Importation de module lorsque 1 fichier de classe 1

Par exemple, si la configuration est la suivante

polls/models/
 ├─ __init__.py
 ├─ question.py ...Seule la question est définie
 └─ choice.py   ...Seul le choix est défini

Pour appeler chaque classe, écrivez:

from polls.models.question import Question
from polls.models.choice import Choice
question = Question()
choice = Choice()

Alternativement, vous pouvez écrire:

from polls import models
question = models.question.Question()
choice = models.choice.Choice()

Vous avez créé un espace de noms dédié pour chaque classe, n'est-ce pas? Je me sens exagéré.

Lorsque toutes les classes sont dans un module

Il a la même structure que le tutoriel.

polls/models.py

Pour appeler la classe, écrivez:

from polls.models import Question, Choice
question = Question()
choice = Choice()

Ou vous pouvez tout importer en utilisant *.

from polls.models import *
question = Question()
choice = Choice()
#Ce n'est pas explicite où et ce que vous avez importé, c'est donc une autre question que vous l'utilisiez ou non.

Je pense que c'est une structure simple où Question``Choice vit dans l'espace de noms polls.models.

Raisons d'utiliser les packages

Alors pourquoi y a-t-il une fonction appelée package? Par exemple, les raisons suivantes sont possibles

• Le nombre de classes et de fonctions a augmenté dans le module
• Certaines classes et fonctions ne sont utilisées que dans les modules. ――La classe s'agrandit et je veux vraiment diviser le fichier

Si cela se produit, la visibilité sera pire si vous n'utilisez pas le package et vous ne pourrez pas garder les choses organisées. Utilisons des packages pour séparer les modules. Je pense qu'il est nécessaire de réfléchir à la manière de découper un module dans un package à chaque fois, en fonction de la destination du package.

La seule chose importante est que ** l'importateur devrait pouvoir y accéder comme s'il s'agissait d'un seul module **.

__Init __. Py pour cela

Par exemple, sur la base de l'exemple du didacticiel précédent (qui n'est peut-être pas très courant), disons que chaque classe est devenue gonflée et que des fonctions d'assistance qui ne sont utilisées que dans les modèles sont apparues, les fichiers sont donc divisés en packages.

polls/models/
 ├─ __init__.py
 ├─ question.py ...La question est définie
 ├─ choice.py   ...Le choix est défini
 └─ helper.py   ...La fonction de commodité est définie

À ce rythme, si vous voulez appeler Question, vous devez écrire depuis polls.models.question import Question. En d'autres termes, la manière d'écrire l'importation changera par rapport à celle d'un seul fichier. S'il s'agissait d'une bibliothèque, ce serait un changement catastrophique affectant l'interface.

Par conséquent, ajoutez ce qui suit au toujours vide «__init __. Py». Il est pratique d'écrire le module cible à partir de . car il devient une référence relative.

polls/models/__init__.py

from .question import Question
from .choice import Choice
# (Je n'écris pas d'aide car il n'est utilisé qu'en interne)

En écrivant ceci, vous pouvez clairement indiquer que " Question Choice est dans l'espace de noms polls.models!", Et vous pouvez écrire import tel quel.

from polls.models import Question, Choice
question = Question()
choice = Choice()

Autrement dit, ** les modules et packages sont des espaces de noms **

―― Je veux que la granularité de l'espace de noms soit appropriée, et c'est un peu étrange de définir un espace de noms pour une seule classe.

• Si vous voulez créer un paquet, c'est une bonne idée d'écrire quelque chose qui est référencé de l'extérieur dans __init __. Py.

Bien entendu, certaines bibliothèques sont conçues pour faire directement référence aux modules du package. Probablement une énorme bibliothèque comme un framework. Même ainsi, les packages finaux sont organisés en pensant à l'utilisateur. Il peut être utile de lire ce code.