Einer der großen Vorteile von Python ist die Fähigkeit, Methoden und Funktionen selbst zu untersuchen. Um beispielsweise die Funktionssignatur von math.log
zu erhalten, können Sie (in ipython) Folgendes ausführen:
Und sehen Sie, dass x
und optional base
die Parameter dieser Funktion sind.
Mit dem neuen gtk3 und den automatisch generierten pygobject Bindings kann ich in allen Beispielen, die ich probiert habe, immer nur (*args, **kwargs)
as bekommen die Parameter jeder gtk-Methode.
Beispiel: Label.set_text , für das eine Zeichenfolge erforderlich ist :
%Vor%JETZT DIE FRAGE: Ist das (der Verlust der Methodenintrospektion für Pythonbindungen) etwas, das sich noch einmal ändern wird (Dokumentationsaufwand) in pygobjects gegangen ist oder ist das etwas, was aufgrund der Funktionsweise von pygobjects so bleiben soll? / p>
Im Moment denke ich, das ist noch nicht fertig. Sie können jedoch weiterhin eine manuelle Introspektion durchführen, indem Sie Gtk-3.0.gir
file betrachten (in meinem System in /usr/share/gir-1.0/Gtk-3.0.gir
).
Die gir-Datei ist nur eine XML-Datei, die genau verwendet werden soll, um die exponierte Schnittstelle unabhängig von der Programmiersprache zu untersuchen, die Sie verwenden. Zum Beispiel kann die Label
-Klasse nach <class name="Label"
suchen. Im class
-Tag gibt es ein doc
-Tag mit umfangreichen Informationen darüber, was dieses Widget tun soll. Außerdem gibt es viele method
-Tags und eines davon ist das, an dem Sie interessiert sind: <method name="set_text"
. Innerhalb dieses method
-Tags gibt es nicht nur ein doc
-Tag, das die Methode beschreibt, sondern auch ein parameters
-Tag, das wiederum einige parameter
-Tags enthält, die zur Beschreibung jedes Parameters in Bezug auf Name und Beschreibung verwendet werden und geben Sie Folgendes ein:
Also alle Informationen sind schon da.
Ich glaube, dass dies die Art und Weise ist, wie die C-API zum Erstellen von Python-Modulen dies tut. Zum Beispiel:
%Vor%Der einzige Weg (den ich kenne) ist, die Methodenparameter für eingebaute Funktionen zu betrachten, ist die Doc-Zeichenkette anzusehen.
%Vor%Ich habe mein eigenes C-Python-Modul geschrieben und nach Möglichkeiten gesucht, das (...) zu "reparieren", und die Problemumgehung besteht darin, es in den Doc-String zu setzen, den ich für fehleranfällig halte Aktualisieren Sie die Doc-Zeichenfolge jedes Mal, wenn ich die Funktion ändere.