Programm soll seine Bedienung aufzeichnen & wieder abspielen können

[LukeNukem]

@LukeNukem: Man könnte auch das hier schreiben:

Code: Alles auswählen

((((((((((fu_x)))))))))) = ((((((((((((((((((((deco_func))))))))))((((((((((fu_x))))))))))))))))))))

Kein Unterschied im Ergebnis.

Oh, stimmt natürlich... *lol* Da bin ich auf genau die Verwirrung durch die überflüssigen Klammern hereingefallen, die ich eigentlich auflösen wollte. Was ich meinte, war natürlich

Code: Alles auswählen

fu_x = deco_func(fu_x)

Danke für den Hinweis!

[__blackjack__]

Was die Klammerei angeht war das bei mir schon *Absicht* das da Klammern um das waren was ich `expr` genannt habe, denn `expr` kann ja ein beliebiger Ausdruck sein, solange da am Ende was aufrufbares heraus kommt was sich entsprechend verhält. Wenn `expr` konkret für ``Foo() + bar`` steht dann macht das einen Unterschied ob man das in Klammern setzt oder nicht:

Code: Alles auswählen

@Foo() + bar
def f(...):
    ...

# <=>

def f(...):
    ...

f = (Foo() + bar)(f)

# und *nicht*

def f(...):
    ...

f = Foo() + bar(f)

[LukeNukem]

Was die Klammerei angeht war das bei mir schon *Absicht* das da Klammern um das waren was ich `expr` genannt habe, denn `expr` kann ja ein beliebiger Ausdruck sein, solange da am Ende was aufrufbares heraus kommt was sich entsprechend verhält. Wenn `expr` konkret für ``Foo() + bar`` steht dann macht das einen Unterschied ob man das in Klammern setzt oder nicht:

Code: Alles auswählen

f = (Foo() + bar)(f)

Dann wäre Foo eine Klasse, die __add__() und __call__() implementiert? Das wäre aber eher ein Fall für den Obfuscated Python Contest, fürchte ich. Echt mal: eine der schönsten Eigenschaften von Python ist, daß ich mir wirklich Mühe geben muß, wenn ich unlesbaren Code schreiben will. Meine vorherige Standardskriptsprache war Perl, und da war es umgekehrt: da mußte ich mir Mühe geben, um lesbaren Code zu schreiben...

[JoePy]

Meine Herren! Vielen Dank für die interessanten Hinweise und Anregungen.

@pillmuncher, LukeNukem, __blackjack__
Ja, es bestätigt meinen Verdacht, dass die Klammern für den Interpreter stehen, damit der erkennt, was als "DekoratorFkt" zu betrachten ist. Beim ersten Mal diese Schreibweise zu lesen, schnallte ich dies nicht gleich.

@__deets__, Sirius3
Ihr bestätigt meinen Verdacht, eine universelle DekoratorFkt für DoUndo kann ich nicht schreiben. Bei der Umsetzung meines "normalen" Programms muss ich gezielt Informationen bereitstellen.

@LukeNukem
Danke für Dein Beispiel, aber <instanz>.__class__.__name__ spuckt mir "nur" den Namen der Klasse aus, nicht die "Bezeichnung/Namen" der konkreten Instanz. Bei Dir wäre dies "a".
@Sirius3 stellt dies in seinem Hinweis klar.

Ich danke Euch allen für Eure Unterstützung. Habe viel gelernt.
Leider auch, dass man nicht einfach ein Dekorator-Konstrukt um eine (auch bestehende) Funktion/Klasse herumbauen und mit genug Hirnschmalz beliebige Zusatzeigenschaften/-funktionen erzeugen kann.
Dies war meine Vorstellung der Dekorator-Konstrukte.
Ebenso, dass es recht schwierig ist, seine Vorstellungen so zu formulieren, dass diese von anderen richtig verstanden/interpretiert werden. Insbesondere, wenn man auf einer Metaebene diskutiert. Aber auf dieser Ebene begreife ich, in Code umsetzen, ist dann "Fleissarbeit".

Damit will ich dieses Thema abschliessen.

Eine letzte Frage, ich hab's (noch) nicht herausgefunden, wie ich zitieren oder Code-Schnipsel ein meinen Text einfügen kann. Wo kann ich dies nachlesen?

[__blackjack__]

@LukeNukem: Ich hab's noch nicht bei Dekoratoren gesehen, aber ich hatte vor einer halben Ewigkeit schon mal mit einer Bibliothek zu tun, die mit ``|`` Operationen verkettet hat die parallel laufen sollten. Das war dann ``co | foo | bar | baz | oc`` wobei `co` das Objekt war das ``|`` überladen hat und die Teile eingesammelt hat, und `oc` war ein Sentinel-Objekt was dem `co`-Objekt signalisiert hat, dass die Liste zuende ist und es losgehen kann. Die Idee war wohl Shell-Syntax wie ``if``/``fi`` zu ”simulieren”.

Man könnte sich auch vorstellen das jemand Funktionskomposition so ähnlich löst, also ``Compose(f) * g * h``. Oder mit `+`.

Der Punkt ist halt, dass die Python-Syntax hinter dem ``@`` bei Dekoratoren beliebige Python-Ausdrücke erlaubt. Ob das nun schöner Code ist oder nicht, wenn man präzise sein will, dann muss man um diesen Ausdruck Klammern setzen wenn man den ”syntaktischen Zucker” erklärt.

[LukeNukem]

Danke für Dein Beispiel, aber <instanz>.__class__.__name__ spuckt mir "nur" den Namen der Klasse aus, nicht die "Bezeichnung/Namen" der konkreten Instanz. Bei Dir wäre dies "a".

Ja, ich weiß. Wie mein Begleittext aber schon sagt: das "a" ist -- für den von Dir geschilderten Anwendungsfall -- völlig unwichtig. Aber natürlich kenne ich Deinen Anwendungsfall nicht gut genug, deswegen sei mir der Hinweis erlaubt sei, daß man Python-Objekte natürlich auch in Klassen zusammenfassen und diese, jedenfalls meistens, serialisieren kann. Es gibt in Python dazu ein Builtin-Modul namens "pickle", das gut funktioniert und sauschnell ist, im Pypi gibt es aber ein Modul mit zusätzlicher Funktionalität namens "dill". Auch "dill" kann leider nicht alles serialisieren, aber deutlich mehr als "pickle"... YMMV, HTH.

[LukeNukem]

@LukeNukem: Ich hab's noch nicht bei Dekoratoren gesehen, aber ich hatte vor einer halben Ewigkeit schon mal mit einer Bibliothek zu tun, die mit ``|`` Operationen verkettet hat die parallel laufen sollten. Das war dann ``co | foo | bar | baz | oc`` wobei `co` das Objekt war das ``|`` überladen hat und die Teile eingesammelt hat, und `oc` war ein Sentinel-Objekt was dem `co`-Objekt signalisiert hat, dass die Liste zuende ist und es losgehen kann.

Sowas hab' ich auch schon gebaut, um komplexe Permissions in einer Flask-basierten Webapplikation mit Flask-Security-Too sauber abzubilden. Im Prinzip ist das ein Mißbrauch von bitweisen Operatoren, aber... naja, was ist schon "schön"? Es funktioniert und ist benutzerfreundlich.

Die Idee war wohl Shell-Syntax wie ``if``/``fi`` zu ”simulieren”.

Manche Menschen können sich auch mit einer Flinte treffsicher in den Fuß schießen...

Der Punkt ist halt, dass die Python-Syntax hinter dem ``@`` bei Dekoratoren beliebige Python-Ausdrücke erlaubt.

Naja, hinter dem "@" steht im Wesentlichen ein Funktionsaufruf. Dem kannst Du als Parameter beliebiges Zeug übergeben, aber... im Kern rufen wir ja immer noch einen Wrapper auf.

Ob das nun schöner Code ist oder nicht, wenn man präzise sein will, dann muss man um diesen Ausdruck Klammern setzen wenn man den ”syntaktischen Zucker” erklärt.

Sei mir bitte nicht böse, aber... das erinnert mich so sehr an Funktionszeiger in C... nein. Da ist eine Zeile Extracode immer besser. Python ist in vielen Punkten auf Lesbarkeit fokussiert, aus guten Gründen, und... da bin ich gerne und jederzeit dabei. *lacht* Hier hat jemand bemäkelt, daß ich nicht die richtigen Bezeichner wähle...

[__blackjack__]

Bei einer extra Zeile müsste man dem Ergebnis von `expr` aber einen Namen geben, und dann zusätzlich noch erklären das der Name aber nur für das Beispiel ist und man sich den weg denken muss, weil der nur intern existiert.