Zusammenfassung

Derzeit erfordert die Anpassung der Klassenerstellung die Verwendung einer benutzerdefinierten Metaklasse. Diese benutzerdefinierte Metaklasse bleibt für den gesamten Lebenszyklus der Klasse bestehen, was das Potenzial für irrtümliche Metaklassenkonflikte schafft.

Diese PEP schlägt vor, stattdessen eine breite Palette von Anpassungsszenarien durch einen neuen Parameter namespace im Klassen-Header und einen neuen Hook __autodecorate__ im Klassen-Body zu unterstützen.

Der neue Mechanismus sollte einfacher zu verstehen und zu verwenden sein als die Implementierung einer benutzerdefinierten Metaklasse und somit eine sanftere Einführung in die volle Leistungsfähigkeit der Metaklassen-Mechanismen von Python bieten.

Rücknahme eines PEP

Dieser Vorschlag wurde zugunsten des Vorschlags von Martin Teichmann in PEP 487 zurückgezogen, der die gleichen Ziele durch einen einfacheren, leichter zu verwendenden __init_subclass__ Hook erreicht, der für die Basisklasse, die den Hook definiert, einfach nicht aufgerufen wird.

Hintergrund

Für eine bereits erstellte Klasse cls hat der Begriff "Metaklasse" eine klare Bedeutung: Es ist der Wert von type(cls).

Während der Klassenerstellung hat er eine andere Bedeutung: Er wird auch verwendet, um sich auf den Metaklassen-Hinweis zu beziehen, der als Teil der Klassendefinition angegeben werden kann. Während sich in vielen Fällen diese beiden Bedeutungen auf dasselbe Objekt beziehen, gibt es zwei Situationen, in denen dies nicht der Fall ist

• Wenn der Metaklassen-Hinweis auf eine Instanz von type verweist, wird er zusammen mit den Metaklassen aller Eltern der zu definierenden Klasse als Kandidaten-Metaklasse betrachtet. Wenn eine geeignetere Metaklasse unter den Kandidaten gefunden wird, wird diese anstelle der im Metaklassen-Hinweis angegebenen verwendet.
• Andernfalls wird davon ausgegangen, dass ein expliziter Metaklassen-Hinweis eine Factory-Funktion ist und direkt aufgerufen wird, um das Klassenobjekt zu erstellen. In diesem Fall wird die endgültige Metaklasse durch die Definition der Factory-Funktion bestimmt. Im typischen Fall (wenn die Factory-Funktion nur type oder in Python 3.3 oder später types.new_class aufruft) wird die tatsächliche Metaklasse dann basierend auf den Elternklassen bestimmt.

Es ist erwähnenswert, dass nur die tatsächliche Metaklasse vererbt wird – eine als Metaklassen-Hook verwendete Factory-Funktion sieht nur die gerade definierte Klasse und wird für keine Unterklassen aufgerufen.

In Python 3 wird der Metaklassen-Hinweis über die metaclass=Meta Keyword-Syntax im Klassen-Header bereitgestellt. Dies ermöglicht die Verwendung der Methode __prepare__ auf der Metaklasse, um den Namensraum locals() zu erstellen, der während der Ausführung des Klassen-Bodies verwendet wird (z. B. die Verwendung von collections.OrderedDict anstelle eines normalen dict).

In Python 2 gab es keine Methode __prepare__ (diese API wurde für Python 3 von PEP 3115 hinzugefügt). Stattdessen konnte ein Klassen-Body das Attribut __metaclass__ setzen, und der Klassenerstellungsprozess extrahierte diesen Wert aus dem Klassen-Namensraum, um ihn als Metaklassen-Hinweis zu verwenden. Es gibt veröffentlichten Code, der diese Funktion nutzt.

Eine weitere neue Funktion in Python 3 ist die Null-Argument-Form des integrierten super(), eingeführt von PEP 3135. Diese Funktion verwendet eine implizite Referenz __class__ auf die zu definierende Klasse, um die "by name"-Referenzen zu ersetzen, die in Python 2 erforderlich waren. So wie Code, der während der Ausführung einer Python 2-Metaklasse aufgerufen wird, keine Methoden aufrufen konnte, die auf die Klasse nach Namen verwiesen (da der Name noch nicht im enthaltenden Gültigkeitsbereich gebunden war), können Python 3-Metaklassen keine Methoden aufrufen, die von der impliziten Referenz __class__ abhängen (da diese erst nach Rückgabe der Metaklasse an die Klassenerstellungs-Mechanismen populär wird).

Schließlich kann die Verwendung einer benutzerdefinierten Metaklasse zusätzliche Herausforderungen für die Nutzung von Mehrfachvererbung mit sich bringen, da eine neue Klasse nicht von Elternklassen mit nicht verwandten Metaklassen erben kann. Dies bedeutet, dass es unmöglich ist, einer bereits veröffentlichten Klasse eine Metaklasse hinzuzufügen: Eine solche Ergänzung ist eine rückwärts inkompatible Änderung aufgrund des Risikos von Metaklassenkonflikten.

Vorschlag

Diese PEP schlägt vor, dass ein neuer Mechanismus zur Anpassung der Klassenerstellung in Python 3.4 hinzugefügt wird, der die folgenden Kriterien erfüllt

1. Lässt sich gut in Klassenerbstrukturen integrieren (einschließlich Mixins und Mehrfachvererbung)
2. Lässt sich gut in die implizite Referenz __class__ und die Null-Argument-Syntax von super() integrieren, die von PEP 3135 eingeführt wurden
3. Kann zu einer bestehenden Basisklasse hinzugefügt werden, ohne ein erhebliches Risiko von Rückwärtskompatibilitätsproblemen einzugehen
4. Stellt die Fähigkeit wieder her, dass Klassen-Namensräume einen Einfluss auf den Klassenerstellungsprozess haben (über das einfache Befüllen des Namensraums hinaus), aber potenziell ohne die volle Flexibilität des Python 2-Stil-Hooks __metaclass__

Ein Mechanismus, der dieses Ziel erreichen kann, ist das Hinzufügen eines neuen impliziten Klassen-Dekorations-Hooks, der direkt an den bestehenden expliziten Klassen-Dekoratoren orientiert ist, aber im Klassen-Body oder in einer Elternklasse definiert ist, anstatt Teil des Klassen-Definitions-Headers zu sein.

Insbesondere wird vorgeschlagen, dass Klassendefinitionen einen Hook zur Klasseninitialisierung wie folgt bereitstellen können

class Example:
    def __autodecorate__(cls):
        # This is invoked after the class is created, but before any
        # explicit decorators are called
        # The usual super() mechanisms are used to correctly support
        # multiple inheritance. The class decorator style signature helps
        # ensure that invoking the parent class is as simple as possible.
        cls = super().__autodecorate__()
        return cls

Zur Vereinfachung des kooperativen Mehrfachvererbungsfalls erhält object eine Standardimplementierung des Hooks, die die Klasse unverändert zurückgibt

class object:
    def __autodecorate__(cls):
        return cls

Wenn eine Metaklasse aus irgendeinem Grund die implizite Klassen-Dekoration blockieren möchte, muss sie sicherstellen, dass cls.__autodecorate__ einen AttributeError auslöst.

Wenn dieser neue Hook auf dem erstellten Objekt vorhanden ist, wird er von der Klassenerstellungs-Mechanik aufgerufen, nachdem die Referenz __class__ initialisiert wurde. Für types.new_class() wird er als letzter Schritt aufgerufen, bevor das erstellte Klassenobjekt zurückgegeben wird. __autodecorate__ wird bei der Erstellung der Klasse implizit in eine Klassenmethode umgewandelt (bevor der Hook aufgerufen wird).

Beachten Sie, dass zum Zeitpunkt des Aufrufs von __autodecorate__ der Name der Klasse noch nicht an das neue Klassenobjekt gebunden ist. Infolgedessen kann die Zwei-Argument-Form von super() nicht verwendet werden, um Methoden aufzurufen (z. B. wäre super(Example, cls) im obigen Beispiel nicht funktionsfähig). Die Null-Argument-Form von super() funktioniert jedoch wie erwartet, da die Referenz __class__ bereits initialisiert ist.

Dieser allgemeine Vorschlag ist keine neue Idee (er wurde zuerst für die Aufnahme in die Sprachdefinition vor mehr als 10 Jahren vorgeschlagen, und ein ähnlicher Mechanismus wird seit langem von Zope's ExtensionClass unterstützt), aber die Situation hat sich in den letzten Jahren ausreichend geändert, dass die Idee eine erneute Berücksichtigung für die Aufnahme als natives Sprachfeature wert ist.

Darüber hinaus ermöglicht die Einführung der Metaklassenmethode __prepare__ in PEP 3115 eine weitere Verbesserung, die in Python 2 nicht möglich war: Diese PEP schlägt außerdem vor, dass type.__prepare__ aktualisiert wird, um eine Factory-Funktion als Keyword-Only-Argument namespace zu akzeptieren. Wenn vorhanden, wird der Wert, der als Argument namespace bereitgestellt wird, ohne Argumente aufgerufen, um das Ergebnis von type.__prepare__ zu erstellen, anstatt eine neu erstellte Dictionary-Instanz zu verwenden. Zum Beispiel wird die folgende Zeile ein geordnetes Dictionary als Klassen-Namensraum verwenden

class OrderedExample(namespace=collections.OrderedDict):
    def __autodecorate__(cls):
        # cls.__dict__ is still a read-only proxy to the class namespace,
        # but the underlying storage is an OrderedDict instance

Hauptvorteile

Design-Überlegungen

class Example:
    def __autodecorate__(cls):
        cls = super().__autodecorate__()
        # Don't process the base class
        if cls is __class__:
            return
        # Process subclasses here
        ...

class BuildDict:
    def __autodecorate__(cls):
        cls = super().__autodecorate__()
        # Don't process the base class
        if cls is __class__:
            return
        # Convert subclasses to ordinary dictionaries
        return cls.__dict__.copy()

Offene Fragen

Neue Wege zur Nutzung von Klassen

Der neue Schlüssel namespace im Klassen-Header ermöglicht eine Reihe interessanter Optionen zur Steuerung der Art und Weise, wie eine Klasse initialisiert wird, einschließlich einiger Aspekte der Objektmodelle von JavaScript und Ruby.

Alle unten aufgeführten Beispiele sind heute tatsächlich durch die Verwendung einer benutzerdefinierten Metaklasse möglich

class CustomNamespace(type):
    @classmethod
    def __prepare__(meta, name, bases, *, namespace=None, **kwds):
        parent_namespace = super().__prepare__(name, bases, **kwds)
        return namespace() if namespace is not None else parent_namespace
    def __new__(meta, name, bases, ns, *, namespace=None, **kwds):
        return super().__new__(meta, name, bases, ns, **kwds)
    def __init__(cls, name, bases, ns, *, namespace=None, **kwds):
        return super().__init__(name, bases, ns, **kwds)

Der Vorteil der direkten Implementierung des neuen Schlüssels in type.__prepare__ ist, dass die *einzige* dauerhafte Auswirkung die Änderung des zugrundeliegenden Speichers der Klassenattribute ist. Die Metaklasse der Klasse bleibt unverändert, wodurch viele der Nachteile, die typischerweise mit diesen Arten von Anpassungen verbunden sind, eliminiert werden.

class OrderedClass(namespace=collections.OrderedDict):
    a = 1
    b = 2
    c = 3

seed_data = dict(a=1, b=2, c=3)
class PrepopulatedClass(namespace=seed_data.copy):
    pass

class NewClass(namespace=Prototype.__dict__.copy):
    pass

from collections import MutableMapping

# The MutableMapping + dict combination should give something that
# generally behaves correctly as a mapping, while still being accepted
# as a class namespace
class ClassNamespace(MutableMapping, dict):
    def __init__(self, cls):
        self._cls = cls
    def __len__(self):
        return len(dir(self._cls))
    def __iter__(self):
        for attr in dir(self._cls):
            yield attr
    def __contains__(self, attr):
        return hasattr(self._cls, attr)
    def __getitem__(self, attr):
        return getattr(self._cls, attr)
    def __setitem__(self, attr, value):
        setattr(self._cls, attr, value)
    def __delitem__(self, attr):
        delattr(self._cls, attr)

def extend(cls):
    return lambda: ClassNamespace(cls)

class Example:
    pass

class ExtendedExample(namespace=extend(Example)):
    a = 1
    b = 2
    c = 3

>>> Example.a, Example.b, Example.c
(1, 2, 3)

Abgelehnte Designoptionen

Referenzimplementierung

Eine Referenzimplementierung für __autodecorate__ wurde auf dem Issue Tracker veröffentlicht. Sie verwendet die ursprüngliche Benennung __init_class__, erlaubt noch nicht, dass der implizite Dekorator die Klasse durch ein anderes Objekt ersetzt und implementiert nicht den vorgeschlagenen Parameter namespace für type.__prepare__.

TODO

• Adresse die 5 Punkte unter https://mail.python.org/pipermail/python-dev/2013-February/123970.html

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.