可以对 pygtk3 进行内省吗？

发布于 2024-12-11 11:33:37 字数 1361 浏览 1 评论 0 原文

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>

NOW问题：这是（Python 绑定的方法内省的丢失）会再次改变（文档）工作已经进入 pygobjects 的东西，还是由于 pygobjects 的工作方式而保留的东西？

原文

One of the great things of python is the ability to have introspection on methods and functions. As an example, to get the function signature of math.log you can (in ipython) run this:

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.

And see that x and optionally base are the parameters of this function.

With the new gtk3 and the automaticall generated pygobject bindings, I can in all examples I tried only ever get (*args, **kwargs) as the parameters of every gtk method.

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

NOW THE QUESTION: is this (the loss of method introspection for python bindings) something that will change once more (documentation) effort has gone into pygobjects or is this something that is here to stay due to the way pygobjects works?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

囚你心 2024-12-18 11:33:37

现在，我认为这还没有准备好。但是，您仍然可以查看 Gtk-3.0.gir 文件（在我的系统中位于 /usr/share/gir-1.0/Gtk-3.0.gir ）。

gir 文件只是一个 xml 文件，无论您使用哪种编程语言，都应该准确地使用它来探索公开的接口。例如，可以通过查找 来找到 Label 类。在 class 标记内有一个 doc 标记，其中包含有关此小部件应该执行的操作的详细信息。此外，还有许多 method 标记，其中一个是您在示例中感兴趣的标记：。在这个 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>

因此所有信息都已存在。

Right now, I think this isn't yet ready. However, you can still do manual introspection looking at Gtk-3.0.gir file (in my system located in /usr/share/gir-1.0/Gtk-3.0.gir).

The gir file is just an xml file that is supposed to be used exactly to explore the exposed interface regardless of the programming language that you are using. For example, the Label class can be found looking for <class name="Label". Inside the class tag there's a doc tag with extensive information about what this widget is supposed to do. Also there are many method tags and one of them is the one you're interested in in you example: <method name="set_text". Inside this method tag there's not only a doc tag that describes the method, but also a parameters tag that, in turn, contains some parameter tag that are used to describe each parameter in terms of name, description and type:

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

So all the information is already there.

回复收藏 0 原文

┈┾☆殇 2024-12-18 11:33:37

我相信这就是创建 python 模块的 C API 的方式。例如：（

>>> 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 模块，并寻找了“修复” (...) 的方法，解决方法是将其放在文档字符串中，我认为这很容易出错，因为我必须更新文档每次我更改函数时都会输入字符串。

I believe this would be the way the C API for creating python modules does it. For example:

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

The only way (that I know of) is to look at method parameters for built-in functions is to look at the doc string.

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

I've written my own C python module, and have looked for ways to "fix" the (...) and the workaround is to place it in the doc string which I consider error prone as I'd have to update the doc string every time I change the function.

回复收藏 0 原文