Возможна ли самоанализ на pygtk3?

Одна из замечательных особенностей Python — это возможность самоанализа методов и функций. Например, чтобы получить сигнатуру функции math.log, вы можете (в ipython) запустить это:

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.

И обратите внимание, что x и, возможно, base являются параметрами этой функции.

С новым gtk3 и автоматически сгенерированными привязками pygobject я могу во всех примерах получить только (*args, **kwargs) как параметры каждого метода gtk.

Пример: Label.set_text для которого требуется строка:

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>

ТЕПЕРЬ ВОПРОС: это (потеря интроспекции методов для привязок python) что-то, что еще раз изменит (документация) усилие, направленное на pygobjects, или это то, что останется здесь из-за того, как работают pygobjects?


python gtk3 pygobject pygtk
person xubuntix    schedule 22.10.2011    source источник
comment
Отличный вопрос. Я бы также рекомендовал спросить об этом в любом списке рассылки, посвященном pygobject.   -  person ptomato    schedule 22.10.2011
comment
Смысл автоматического создания привязок в том, что одна и та же документация C, созданная с помощью gtk-doc, работает для каждого языка. Итак, что, на мой взгляд, должно быть полезно, так это то, что разработчики pygi генерируют документы для python так же, как и для привязок.   -  person erick2red    schedule 24.10.2011

Ответы (3)


arrow_upward
4
arrow_downward

Сейчас я думаю, что это еще не готово. Тем не менее, вы все еще можете выполнять самоанализ вручную, просматривая файл Gtk-3.0.gir (в моей системе он находится в /usr/share/gir-1.0/Gtk-3.0.gir).

Файл gir — это просто файл xml, который предполагается использовать именно для изучения открытого интерфейса, независимо от используемого вами языка программирования. Например, класс Label можно найти в поисках <class name="Label". Внутри тега class есть тег doc с подробной информацией о том, что должен делать этот виджет. Также есть много тегов method и один из них тот, который вас интересует в вашем примере: <method name="set_text". Внутри этого тега method есть не только тег doc, описывающий метод, но и тег parameters, который, в свою очередь, содержит некоторые теги parameter, которые используются для описания каждого параметра с точки зрения имени, описания и типа:

<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>

Так что вся информация уже есть.

person jcollado    schedule 10.11.2011
comment
Итак, я пришел к выводу, что привязки python по-прежнему будут иметь нарушенный самоанализ (из-за магических параметров, которые они используют для создания API), но могут получить по крайней мере рабочую встроенную документацию. - person xubuntix; 11.11.2011
comment
Это всего лишь предположение, но я бы сказал, что документация действительно будет на первом месте, но в конечном итоге будут добавлены некоторые возможности самоанализа. - person jcollado; 11.11.2011

arrow_upward
0
arrow_downward

Я считаю, что это будет то, как это делает C API для создания модулей Python. Например:

>>> 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

Единственный способ (известный мне) — посмотреть параметры метода для встроенных функций — посмотреть строку документа.

>>> 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.

Я написал свой собственный модуль C python и искал способы «исправить» (...), и обходной путь состоит в том, чтобы поместить его в строку документа, которую я считаю подверженной ошибкам, поскольку мне придется обновить документ string каждый раз, когда я меняю функцию.

person David    schedule 24.10.2011

arrow_upward
0
arrow_downward

Вы можете использовать другие встроенные функции, такие как dir(), vars() и т. д.

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

Еще одним полезным инструментом является pydoc:

pydoc gi.repository.Gtk
person shakaran    schedule 01.11.2011
comment
pydoc gi.repository.Gtk.Label показывает метод set_text как: set_text(*args, **kwargs) так что это то же самое, что и мой пример. Метод, который я упомянул в вопросе (ipython с?), Просто использует эти встроенные функции. Они не работают с pygobject (точнее: они работают, но просто возвращают эти «магические» аргументы). - person xubuntix; 01.11.2011