Module und Pakete in Python sind "Namespaces"

Motivation zum Schreiben dieses Artikels

• Es ist schwierig, die Philosophie "1 Klasse 1 Datei" in anderen Sprachen einzuführen, ohne das Verpackungssystem von Python zu verstehen. ――Ich sehe oft den Einführungsartikel "Sie können so schreiben, wenn Sie Module und Pakete verwenden", aber es ist schwierig, die Diskussion darüber zu sehen, wie es verwendet werden soll (insbesondere was ist "__init __. Py"? "). weiß nicht) ――Ich will es nicht erzwingen, ist es nicht so als Basis? Ich möchte reden

Wenn es so etwas wie "Schreiben Sie es richtig in diesen Artikel oder dieses Dokument" gibt, wäre ich Ihnen dankbar, wenn Sie es mich wissen lassen könnten.

Nachteile der Trennung von Dateien nach Klassen

In Sprachen wie Java und C #, die durch die Objektorientierung eingeschränkt sind, ist es meiner Meinung nach üblich, eine öffentliche Klasse pro Datei zu schreiben.

Aber in Python sind "~ .py" alle Module, und Module sind eine Reihe von Funktionen, die sie bereitstellen. Ich denke, das Modul kann mehrere Klassen haben.

In Djangos models.py (dem Standardmodul, das die ORM-Entitätsklasse implementiert) wird beispielsweise ein Bild zum Schreiben aller Entitätsklassen in einer Zeile angezeigt.

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)

Auszug aus "Erstellen Ihrer ersten Django-App, Teil 2"

In der Praxis mag es selten vorkommen, dass diese Anzahl von Zeilen passt, aber ist es so vorteilhaft, eine Klasse von höchstens ein paar Zeilen in eine separate Datei zu trennen? Wenn sich die Sprache ändert, ändert sich natürlich auch der gesunde Menschenverstand. Ich denke, dass es in Python anders ist, eine Klasse und eine Datei wie angegeben zu behandeln.

Der größte Grund, warum ich das so finde, ist, dass es sich auf das Schreiben von "Import" auswirkt.

Modulimport bei 1 Klasse 1 Datei

Zum Beispiel, wenn die Konfiguration wie folgt ist

polls/models/
 ├─ __init__.py
 ├─ question.py ...Es ist nur die Frage definiert
 └─ choice.py   ...Es ist nur die Auswahl definiert

Um jede Klasse aufzurufen, schreiben Sie:

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

Alternativ können Sie schreiben:

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

Sie haben für jede Klasse einen eigenen Namespace erstellt, oder? Ich fühle mich übertrieben.

Wenn sich alle Klassen in einem Modul befinden

Es hat die gleiche Struktur wie das Tutorial.

polls/models.py

Um die Klasse aufzurufen, schreiben Sie:

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

Oder Sie können alles mit * importieren.

from polls.models import *
question = Question()
choice = Choice()
#Es ist nicht explizit, wo und was Sie importiert haben, daher ist es eine andere Frage, ob Sie es verwenden oder nicht.

Ich denke, es ist eine einfache Struktur, in der Question``Choice im Namespace polls.models lebt.

Gründe für die Verwendung von Paketen

Warum gibt es eine Funktion namens Paket? Zum Beispiel sind die folgenden Gründe möglich

• Die Anzahl der Klassen und Funktionen im Modul hat zugenommen
• Es gibt einige Klassen und Funktionen, die nur in Modulen verwendet werden. ――Die Klasse wird größer und ich möchte die Datei wirklich teilen

In diesem Fall ist die Sichtbarkeit schlechter, wenn Sie das Paket nicht verwenden, und Sie können die Dinge nicht organisieren. Verwenden wir Pakete, um Module zu trennen. Ich denke, es ist notwendig, jedes Mal darüber nachzudenken, wie ein Modul in ein Paket geschnitten werden kann, je nachdem, wofür das Paket gedacht ist.

Das einzig Wichtige ist, dass ** der Importeur darauf zugreifen kann, als wäre es ein einzelnes Modul **.

__Init __. Py dafür

Angenommen, basierend auf dem Beispiel im vorherigen Lernprogramm (das möglicherweise nicht sehr häufig vorkommt), ist jede Klasse aufgebläht und es wurden Hilfsfunktionen angezeigt, die nur von Modellen verwendet werden. Daher werden die Dateien in Pakete unterteilt.

polls/models/
 ├─ __init__.py
 ├─ question.py ...Frage ist definiert
 ├─ choice.py   ...Auswahl ist definiert
 └─ helper.py   ...Komfortfunktion ist definiert

Wenn Sie bei dieser Rate "Frage" aufrufen möchten, müssen Sie "aus polls.models.question import Question" schreiben. Mit anderen Worten, die Art und Weise, wie der Import geschrieben wird, ändert sich im Vergleich zu einer Datei. Wenn dies eine Bibliothek wäre, wäre dies eine katastrophale Änderung, die sich auf die Schnittstelle auswirkt.

Fügen Sie daher dem immer leeren "__init __. Py" Folgendes hinzu. Es ist zweckmäßig, das Zielmodul aus "." Zu schreiben, da es zu einer relativen Referenz wird.

polls/models/__init__.py

from .question import Question
from .choice import Choice
# (Ich schreibe keinen Helfer, weil er nur intern verwendet wird)

Wenn Sie dies schreiben, können Sie klar angeben, dass " Question Choice im Namespace" polls.models`! "Ist, und Sie können den Import so schreiben, wie er ist.

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

Das heißt, ** Module und Pakete sind Namespaces **

――Ich möchte, dass die Granularität des Namespace angemessen ist, und es ist etwas seltsam, einen Namespace nur für eine Klasse zu definieren.

• Wenn Sie ein Paket erstellen möchten, ist es eine gute Idee, etwas zu schreiben, auf das von außen in "__init __. Py" verwiesen wird.

Natürlich sind einige Bibliotheken so konzipiert, dass sie direkt auf die Module im Paket verweisen. Wahrscheinlich eine riesige Bibliothek wie ein Framework. Trotzdem sind die Endpakete für den Benutzer organisiert. Es kann hilfreich sein, solchen Code zu lesen.