search

pygobject / pgi-docgen

API Documentation Generator for PyGObject
https://lazka.github.io/pgi-docs/
GNU Lesser General Public License v2.1
127 stars 36 forks source link

Struct fields have incorrect annotations if they match a top-level module symbol #177

Closed kaiw closed 5 years ago

kaiw commented 5 years ago

See e.g., https://lazka.github.io/pgi-docs/#GLib-2.0/classes/MemVTable.html for an example of this. The calloc field is of type object; the other fields have incorrect annotations of the top-level function. calloc is the only field that is not exposed as a top-level function.

I've chased this down as far as pgi.util.import_attribute(), invoked from InterfaceField.setup(). While I'm not familiar with the code, I feel like using the imported module attribute as the py_type here is the problem, but... I'm just not confident.

This causes errors in the generated typing stubs, e.g.,

GLib.pyi:712: error: Invalid type "gi.repository.GLib.IOFuncs.io_create_watch"
GLib.pyi:1004: error: Invalid type "gi.repository.GLib.MemVTable.free"
lazka commented 5 years ago

Somewhat fixed with https://github.com/pygobject/pgi/commit/f9329ff0b7923dc1ec3b5adeb03e5fd7c5dd3dfd

kaiw commented 5 years ago

Yeah that seems to fix these cases for stub generation, thanks! There's one more odd one which is _Value__data__union in GObject, but I'm pretty sure that's a different problem.

As far as I'm concerned this is fixed, but I don't know whether you want to leave this open.

lazka commented 5 years ago

There's one more odd one which is _Value__data__union in GObject

That's in the gir as well, don't know. I'd say it's fine to just backlist some things in glib/gobject if they make problems.

As far as I'm concerned this is fixed, but I don't know whether you want to leave this open.

I'm fine with it.. the longterm goal is to get rid of pgi anyway.