L'introspezione su pygtk3 è possibile?

Question

Una delle grandi cose di Python è la capacità di avere un'introspezione su metodi e funzioni. A titolo di esempio, per ottenere la firma funzione del math.log è possibile (in ipython) eseguire questo:

In [1]: math.log? 
Type:  builtin_function_or_method 
Base Class: <type 'builtin_function_or_method'> 
String Form: <built-in function log> 
Namespace: Interactive 
Docstring: 
    log(x[, base]) 

    Return the logarithm of x to the given base. 
    If the base not specified, returns the natural logarithm (base e) of x. 

E vedere che x e opzionalmente base sono i parametri di questa funzione.

Con il nuovo gtk3 e lo automaticall generated pygobject bindings, in tutti gli esempi ho provato sempre e solo a ottenere (*args, **kwargs) come parametri di ogni metodo gtk.

Esempio: Label.set_text which requires a string:

In [1]: from gi.repository import Gtk 
In [2]: mylabel = Gtk.Label("hello") 
In [3]: mylabel.set_text? 
Type:  instancemethod 
Base Class: <type 'instancemethod'> 
String Form: <bound method Label.set_text of <Label object at 0x275b230 (GtkLabel at 0x28cd040)>> 
Namespace: Interactive 
File:  /usr/lib/python2.7/dist-packages/gi/types.py 
Definition: L.set_text(*args, **kwargs) 
Docstring: 
    <no docstring> 

ora la domanda: è questo (la perdita di metodo di introspezione per i binding python) qualcosa che cambierà ancora una volta (documentazione) sforzo è andato in pygobjects o è questo qualcosa che è qui per rimanere a causa del modo in cui Pygobjects funziona?

Answer 1

In questo momento, penso questo non è ancora pronto. Tuttavia, è ancora possibile eseguire l'introspezione manuale guardando il file Gtk-3.0.gir (nel mio sistema situato in /usr/share/gir-1.0/Gtk-3.0.gir).

Il file gir è solo un file xml che dovrebbe essere utilizzato esattamente per esplorare l'interfaccia esposta indipendentemente dal linguaggio di programmazione che si sta utilizzando. Ad esempio, è possibile trovare la classe Label alla ricerca di <class name="Label". All'interno del tag class c'è un tag doc con informazioni dettagliate su cosa dovrebbe fare questo widget. Inoltre ci sono molti tag method e uno di questi è quello che ti interessa nel tuo esempio: <method name="set_text". All'interno di questo method tag non c'è solo un tag doc che descrive il metodo, ma anche un tag parameters che, a sua volta, contiene alcune parameter tag che vengono utilizzati per descrivere ciascun parametro in termini di nome, la descrizione e il tipo:

<parameters> 
    <parameter name="str" transfer-ownership="none"> 
    <doc xml:whitespace="preserve">The text you want to set</doc> 
    <type name="utf8" c:type="gchar*"/> 
    </parameter> 
</parameters> 

Quindi tutte le informazioni sono già lì.

Answer 2

Credo che questo sarebbe il modo in cui l'API C per la creazione di moduli Python lo fa. Per esempio:

>>> import inspect 
>>> inspect.getargspec(math.log) 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
    File "C:\Python27\lib\inspect.py", line 813, in getargspec 
    raise TypeError('{!r} is not a Python function'.format(func)) 
TypeError: <built-in function log> is not a Python function 

L'unico modo (che io sappia) è quello di guardare i parametri del metodo per le funzioni built-in è quello di guardare la stringa doc.

>>> help(math.log) 
Help on built-in function log in module math: 

log(...) 
    log(x[, base]) 

    Return the logarithm of x to the given base. 
    If the base not specified, returns the natural logarithm (base e) of x. 

ho scritto il mio modulo C python, e ho cercato il modo per "risolvere" il (...) e la soluzione è metterlo in doc string che considero soggetto a errori, come ho 'Devo aggiornare la stringa doc ogni volta che cambio la funzione.

Answer 3

È possibile utilizzare un altro funzioni built-in come dir(), Vars(), ecc

http://docs.python.org/library/functions.html

Altri strumenti utili è pydoc:

pydoc gi.repository.Gtk