After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 682405 - Refactor PyGEnum and PyGFlags
Refactor PyGEnum and PyGFlags
Status: RESOLVED OBSOLETE
Product: pygobject
Classification: Bindings
Component: gobject
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2012-08-21 23:09 UTC by Simon Feltman
Modified: 2018-01-10 20:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Simon Feltman 2012-08-21 23:09:37 UTC
A few issues stuck out while reading code for fixing: https://bugzilla.gnome.org/show_bug.cgi?id=682323

- Reference counting should be reviewed and tests written to verify what is expected. One ref for module level reference and one ref for Enum class var reference seemed right, but I was seeing there were 4.

- It doesn't seem like any of this is nessessary because these methods are inherited or assigned to the dynamic sub-class:
#if PY_VERSION_HEX < 0x03000000
    PyGFlags_Type.tp_new = pyg_flags_new;
#else
    PyGFlags_Type.tp_new = PyLong_Type.tp_new;
    PyGFlags_Type.tp_hash = PyLong_Type.tp_hash;
#endif

- Clarity is needed between how these functions interact either through actual code refactoring or comments or both:
 pyg_enum_val_new
 pyg_enum_new
 pyg_enum_from_gtype
 pyg_enum_add

For example, pyg_enum_add dynamically creates an enum class and assigns the tp_new slot but when creating the initial __enum_values__ it circumvents this construction to actually create the values returned from tp_new.
Comment 1 Simon Feltman 2013-01-27 12:44:48 UTC
After going through bug 690455 and bug 692515, enums and flags definitely need an overhaul.

When Enums are pulled in through gi without a GType getter (glib:get-type property in the gir), pyobject will create a new GType and register it with GLib. This registered type is then used to construct the Python enum class. It doesn't seem like registering a new GType is needed because it is only being used as a way to translate from gi to python, using a GType enum as an intermediate.

One approach here would be to write basic Enum and Flags classes in pure python. We would then have factory methods that accept a dictionary containing the enum key names and values from which a new sub-class is created and populated. The dictionary can come from gi information when available but when it is not, the information can be taken from glibs type system directly.
Comment 2 GNOME Infrastructure Team 2018-01-10 20:19:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pygobject/issues/31.