WarnungWarnungWarnung

Dieses Dokument soll die Dekorator-Syntax und den Prozess beschreiben, der zu den getroffenen Entscheidungen geführt hat. Es versucht nicht, die riesige Anzahl potenzieller alternativer Syntaxen abzudecken, noch ist es ein Versuch, alle positiven und negativen Aspekte jeder Form erschöpfend aufzulisten.

Zusammenfassung

Die aktuelle Methode zur Transformation von Funktionen und Methoden (z. B. Deklarieren als Klassen- oder statische Methode) ist umständlich und kann zu schwer verständlichem Code führen. Idealerweise sollten diese Transformationen an derselben Stelle im Code vorgenommen werden, an der die Deklaration selbst erfolgt. Dieses PEP führt eine neue Syntax für Transformationen einer Funktions- oder Methodendeklaration ein.

Motivation

Die aktuelle Methode zur Anwendung einer Transformation auf eine Funktion oder Methode platziert die eigentliche Transformation nach dem Funktionskörper. Bei großen Funktionen trennt dies eine Schlüsselkomponente des Verhaltens der Funktion von der Definition der restlichen externen Schnittstelle der Funktion. Zum Beispiel

def foo(self):
    perform method operation
foo = classmethod(foo)

Dies wird bei längeren Methoden weniger lesbar. Es erscheint auch weniger Python-typisch, die Funktion dreimal für etwas zu benennen, das konzeptionell eine einzige Deklaration ist. Eine Lösung für dieses Problem ist, die Transformation der Methode näher an die Deklaration der Methode selbst zu verschieben. Die Absicht der neuen Syntax ist es, zu ersetzen

def foo(cls):
    pass
foo = synchronized(lock)(foo)
foo = classmethod(foo)

mit einer Alternative, die die Dekoration in der Funktionsdeklaration platziert

@classmethod
@synchronized(lock)
def foo(cls):
    pass

Auch Modifikationen von Klassen auf diese Weise sind möglich, obwohl die Vorteile nicht so unmittelbar ersichtlich sind. Fast sicher könnte alles, was mit Klassendekoratoren getan werden könnte, mit Metaklassen getan werden, aber die Verwendung von Metaklassen ist ausreichend obskur, dass es eine gewisse Anziehungskraft hat, einen einfacheren Weg zu haben, einfache Modifikationen an Klassen vorzunehmen. Für Python 2.4 werden nur Funktions-/Methodendekoratoren hinzugefügt.

PEP 3129 schlägt die Hinzufügung von Klassendekoratoren ab Python 2.6 vor.

Hintergrund

Es gibt allgemeine Zustimmung, dass syntaktische Unterstützung wünschenswert ist, um den aktuellen Stand der Dinge zu verbessern. Guido erwähnte syntaktische Unterstützung für Dekoratoren in seiner Keynote-Präsentation auf dem DevDay bei der 10. Python-Konferenz, obwohl er später sagte, es sei nur eine von mehreren Erweiterungen gewesen, die er dort „halbernst“ vorgeschlagen habe. Michael Hudson brachte das Thema kurz nach der Konferenz auf python-dev zur Sprache und schrieb die anfängliche Klammersyntax einer früheren Einreichung auf comp.lang.python von Gareth McCaughan zu.

Klassendekorationen scheinen ein offensichtlicher nächster Schritt zu sein, da Klassendefinitionen und Funktionsdefinitionen syntaktisch ähnlich sind, aber Guido bleibt unentschlossen, und Klassendekoratoren werden fast sicher nicht in Python 2.4 enthalten sein.

Die Diskussion setzte sich von Februar 2002 bis Juli 2004 auf und ab auf python-dev fort. Hunderte von Beiträgen wurden gemacht, wobei Leute viele mögliche Syntaxvariationen vorschlugen. Guido nahm eine Liste von Vorschlägen zur EuroPython 2004 mit, wo eine Diskussion stattfand. Danach entschied er, dass wir die Java-ähnliche @-Dekorator-Syntax erhalten würden, und diese erschien erstmals in 2.4a2. Barry Warsaw nannte diese die ‚Pie-Decorator‘-Syntax, zu Ehren des Pie-thon Parrot Shootouts, der etwa zur gleichen Zeit wie die Dekorator-Syntax stattfand, und weil das @ ein wenig wie eine Torte aussieht. Guido legte seinen Fall dar auf Python-dev, einschließlich dieses Stücks über einige der (vielen) abgelehnten Formen.

Zum Namen „Decorator“

Es gab eine Reihe von Beschwerden über die Wahl des Namens ‚decorator‘ für diese Funktion. Die wichtigste ist, dass der Name nicht mit seiner Verwendung im GoF-Buch übereinstimmt. Der Name ‚decorator‘ ist wahrscheinlich mehr seiner Verwendung im Compilerbereich geschuldet – ein Syntaxbaum wird durchlaufen und annotiert. Es ist durchaus möglich, dass ein besserer Name auftaucht.

Designziele

Die neue Syntax sollte

• für beliebige Wrapper funktionieren, einschließlich benutzerdefinierter aufrufbarer Objekte und der vorhandenen Builtins classmethod() und staticmethod(). Diese Anforderung bedeutet auch, dass eine Dekorator-Syntax die Übergabe von Argumenten an den Wrapper-Konstruktor unterstützen muss
• mit mehreren Wrappern pro Definition funktionieren
• offensichtlich machen, was passiert; zumindest sollte es offensichtlich sein, dass neue Benutzer es beim Schreiben ihres eigenen Codes sicher ignorieren können
• eine Syntax sein, die „... leicht zu merken ist, sobald sie erklärt wurde“
• zukünftige Erweiterungen nicht erschweren
• einfach zu tippen sein; Programme, die sie verwenden, werden sie voraussichtlich sehr häufig verwenden
• nicht erschweren, Code schnell zu scannen. Es sollte immer noch einfach sein, nach allen Definitionen, einer bestimmten Definition oder den Argumenten, die eine Funktion akzeptiert, zu suchen
• sekundäre Support-Tools wie sprachsensitive Editoren und andere „Spielzeugparser-Tools da draußen“ nicht unnötig verkomplizieren
• zukünftigen Compilern die Optimierung von Dekoratoren ermöglichen. Mit der Hoffnung, dass irgendwann ein JIT-Compiler für Python existieren wird, erfordert dies, dass die Syntax für Dekoratoren vor der Funktionsdefinition kommt
• von Ende der Funktion, wo sie derzeit versteckt ist, nach vorne verschoben werden, wo sie mehr ins Auge fällt ins Auge fällt

Andrew Kuchling hat Links zu vielen der Diskussionen über Motivationen und Anwendungsfälle in seinem Blog. Besonders hervorzuheben ist Jim Huginins Liste von Anwendungsfällen.

Aktuelle Syntax

Die aktuelle Syntax für Funktionsdekreatoren, wie in Python 2.4a2 implementiert, ist

@dec2
@dec1
def func(arg1, arg2, ...):
    pass

Dies ist äquivalent zu

def func(arg1, arg2, ...):
    pass
func = dec2(dec1(func))

ohne die zwischenzeitliche Zuweisung an die Variable func. Die Dekoratoren befinden sich in der Nähe der Funktionsdeklaration. Das @-Zeichen macht deutlich, dass hier etwas Neues geschieht.

Die Begründung für die Reihenfolge der Anwendung (von unten nach oben) ist, dass sie der üblichen Reihenfolge der Funktionsanwendung entspricht. In der Mathematik übersetzt sich die Komposition von Funktionen (g o f)(x) zu g(f(x)). In Python übersetzt sich @g @f def foo() zu foo=g(f(foo).

Die Dekoratoranweisung ist in dem, was sie akzeptieren kann, begrenzt – beliebige Ausdrücke funktionieren nicht. Guido bevorzugte dies wegen eines Bauchgefühls.

Die aktuelle Syntax erlaubt auch Dekorator-Deklarationen, die eine Funktion aufrufen, die einen Dekorator zurückgibt

@decomaker(argA, argB, ...)
def func(arg1, arg2, ...):
    pass

Dies ist äquivalent zu

func = decomaker(argA, argB, ...)(func)

Die Begründung für eine Funktion, die einen Dekorator zurückgibt, ist, dass der Teil nach dem @-Zeichen als Ausdruck betrachtet werden kann (obwohl syntaktisch auf nur eine Funktion beschränkt), und was auch immer dieser Ausdruck zurückgibt, wird aufgerufen. Siehe Deklarationsargumente.

Syntax-Alternativen

Es gab eine große Anzahl verschiedener Syntaxen, die vorgeschlagen wurden – anstatt zu versuchen, diese einzelnen Syntaxen durchzugehen, ist es lohnenswert, die Syntaxdiskussion in eine Reihe von Bereichen zu zerlegen. Der Versuch, jede mögliche Syntax einzeln zu diskutieren, wäre Wahnsinn und würde ein völlig unhandliches PEP ergeben.

@classmethod
def foo(arg1,arg2):
    pass

@accepts(int,int)
@returns(float)
def bar(low,high):
    pass

def @classmethod foo(arg1,arg2):
    pass

def @accepts(int,int),@returns(float) bar(low,high):
    pass

def foo @classmethod (arg1,arg2):
    pass

def bar @accepts(int,int),@returns(float) (low,high):
    pass

def foo(arg1,arg2) @classmethod:
    pass

def bar(low,high) @accepts(int,int),@returns(float):
    pass

def foo(arg1,arg2):
    @classmethod
    pass

def bar(low,high):
    @accepts(int,int)
    @returns(float)
    pass

decorate:
    classmethod
    def foo(arg1,arg2):
        pass

decorate:
    accepts(int,int)
    returns(float)
    def bar(low,high):
        pass

Aktuelle Implementierung, Geschichte

Guido bat um einen Freiwilligen, um seine bevorzugte Syntax zu implementieren, und Mark Russell trat hervor und postete einen Patch an SF. Diese neue Syntax war in 2.4a2 verfügbar.

@dec2
@dec1
def func(arg1, arg2, ...):
    pass

Dies ist äquivalent zu

def func(arg1, arg2, ...):
    pass
func = dec2(dec1(func))

jedoch ohne die Zwischenerstellung einer Variablen namens func.

Die in 2.4a2 implementierte Version erlaubte mehrere @decorator-Klauseln auf einer einzigen Zeile. In 2.4a3 wurde dies verschärft, sodass nur noch ein Dekorator pro Zeile erlaubt ist.

Ein früherer Patch von Michael Hudson, der die List-after-def-Syntax implementiert, ist ebenfalls noch im Umlauf.

Nach der Veröffentlichung von 2.4a2 erklärte Guido als Reaktion auf das Community-Feedback, dass er einen Community-Vorschlag erneut prüfen werde, wenn die Community einen Community-Konsens, einen anständigen Vorschlag und eine Implementierung vorlegen könne. Nach einer erstaunlichen Anzahl von Beiträgen, die eine riesige Menge an Alternativen im Python-Wiki sammelten, entstand ein Community-Konsens (unten). Guido lehnte diese alternative Form anschließend ab, fügte aber hinzu

In Python 2.4a3 (das diese Woche am Donnerstag veröffentlicht wird) bleibt alles wie derzeit in CVS. Für 2.4b1 werde ich eine Änderung von @ zu einem anderen Einzelzeichen in Betracht ziehen, obwohl ich denke, dass @ den Vorteil hat, das gleiche Zeichen wie ein ähnliches Feature in Java zu sein. Es wurde argumentiert, dass es nicht ganz dasselbe ist, da @ in Java für Attribute verwendet wird, die die Semantik nicht ändern. Aber Pythons dynamische Natur macht, dass seine syntaktischen Elemente nie ganz dieselbe Bedeutung haben wie ähnliche Konstrukte in anderen Sprachen, und es gibt definitiv eine signifikante Überlappung. Bezüglich der Auswirkungen auf Drittanbieter-Tools: Der Autor von IPython glaubt nicht, dass es große Auswirkungen haben wird; der Autor von Leo hat gesagt, dass Leo überleben wird (obwohl es ihm und seinen Benutzern einige Übergangsschwierigkeiten bereiten wird). Ich erwarte tatsächlich, dass die Wahl eines Zeichens, das bereits anderswo in Pythons Syntax verwendet wird, für externe Tools schwieriger anzupassen sein könnte, da das Parsen in diesem Fall subtiler sein muss. Aber ich bin ehrlich gesagt unentschlossen, also gibt es hier etwas Spielraum. Ich möchte zu diesem Zeitpunkt keine weiteren syntaktischen Alternativen mehr in Betracht ziehen: die Bürokratie muss irgendwann aufhören, jeder hat gesagt, was er zu sagen hat, und die Show muss weitergehen.

using:
    classmethod
    synchronized(lock)
def func(cls):
    pass

Beispiele

Ein Großteil der Diskussionen auf comp.lang.python und der python-dev Mailingliste konzentriert sich auf die Verwendung von Dekoratoren als saubereren Weg zur Verwendung der Builtins staticmethod() und classmethod(). Diese Funktionalität ist weitaus leistungsfähiger. Dieser Abschnitt präsentiert einige Anwendungsbeispiele.

1. Definieren einer Funktion, die beim Beenden ausgeführt werden soll. Beachten Sie, dass die Funktion im üblichen Sinne nicht tatsächlich „umhüllt“ wird.

   def onexit(f):
       import atexit
       atexit.register(f)
       return f
   
   @onexit
   def func():
       ...
   

   Beachten Sie, dass dieses Beispiel wahrscheinlich nicht für den realen Gebrauch geeignet ist, sondern nur zu Demonstrationszwecken dient.

2. Definieren einer Klasse mit einer Singleton-Instanz. Beachten Sie, dass findige Programmierer nach dem Verschwinden der Klasse kreativer sein müssten, um weitere Instanzen zu erstellen. (Von Shane Hathaway auf python-dev.)

   def singleton(cls):
       instances = {}
       def getinstance():
           if cls not in instances:
               instances[cls] = cls()
           return instances[cls]
       return getinstance
   
   @singleton
   class MyClass:
       ...
   

3. Hinzufügen von Attributen zu einer Funktion. (Basierend auf einem Beispiel, das Anders Munch auf python-dev gepostet hat.)

   def attrs(**kwds):
       def decorate(f):
           for k in kwds:
               setattr(f, k, kwds[k])
           return f
       return decorate
   
   @attrs(versionadded="2.2",
          author="Guido van Rossum")
   def mymethod(f):
       ...
   

4. Erzwingen von Funktionsargument- und Rückgabetypen. Beachten Sie, dass dies das func_name-Attribut von der alten zur neuen Funktion kopiert. func_name war in Python 2.4a3 schreibbar

   def accepts(*types):
       def check_accepts(f):
           assert len(types) == f.func_code.co_argcount
           def new_f(*args, **kwds):
               for (a, t) in zip(args, types):
                   assert isinstance(a, t), \
                          "arg %r does not match %s" % (a,t)
               return f(*args, **kwds)
           new_f.func_name = f.func_name
           return new_f
       return check_accepts
   
   def returns(rtype):
       def check_returns(f):
           def new_f(*args, **kwds):
               result = f(*args, **kwds)
               assert isinstance(result, rtype), \
                      "return value %r does not match %s" % (result,rtype)
               return result
           new_f.func_name = f.func_name
           return new_f
       return check_returns
   
   @accepts(int, (int,float))
   @returns((int,float))
   def func(arg1, arg2):
       return arg1 * arg2
   

5. Erklären, dass eine Klasse eine bestimmte (Menge von) Schnittstelle(n) implementiert. Dies stammt aus einem Beitrag von Bob Ippolito auf python-dev basierend auf Erfahrungen mit PyProtocols.

   def provides(*interfaces):
        """
        An actual, working, implementation of provides for
        the current implementation of PyProtocols.  Not
        particularly important for the PEP text.
        """
        def provides(typ):
            declareImplementation(typ, instancesProvide=interfaces)
            return typ
        return provides
   
   class IBar(Interface):
        """Declare something about IBar here"""
   
   @provides(IBar)
   class Foo(object):
           """Implement something here..."""
   

Natürlich sind all diese Beispiele heute möglich, wenn auch ohne syntaktische Unterstützung.

(Nicht mehr) offene Fragen

1. Es ist noch nicht sicher, ob Klassendekoratoren zu einem späteren Zeitpunkt in die Sprache aufgenommen werden. Guido äußerte Skepsis gegenüber dem Konzept, aber verschiedene Leute haben einige starke Argumente (suchen Sie nach PEP 318 -- posting draft) in python-dev dafür vorgebracht. Es ist äußerst unwahrscheinlich, dass Klassendekoratoren in Python 2.4 enthalten sein werden.

   PEP 3129 schlägt die Hinzufügung von Klassendekoratoren ab Python 2.6 vor.

2. Die Wahl des @-Zeichens wird vor Python 2.4b1 erneut geprüft.

   Am Ende wurde das @-Zeichen beibehalten.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.