GFlags instance value_nicks, value_names always includes the name for zero, if any
Steps to reproduce:
>>> from gi.repository import GLib
# GLib.KeyFileFlags includes {G_KEY_FILE_NONE = 0}
>>> GLib.KeyFileFlags.KEEP_COMMENTS.value_nicks
['none', 'keep_comments']
>>> GLib.KeyFileFlags.KEEP_COMMENTS.value_names
['G_KEY_FILE_NONE', 'G_KEY_FILE_KEEP_COMMENTS']
# GLib.AsciiType does not include any member with value 0
>>> GLib.AsciiType.ALNUM.value_nicks
['alnum']
>>> GLib.AsciiType.ALNUM.value_names
['G_ASCII_ALNUM']
Expected result: I would expect GLib.KeyFileFlags.KEEP_COMMENTS.value_nicks
to be ['keep_comments']
, and similar for value_names
.
Actual result: If the GFlags has a name for 0 (typically NONE
, DEFAULT
or NO_FLAGS
) then it is included in the value_nicks
and value_names
for every nonzero value as well. Is this intentional?
The __repr__
has the behaviour I would have expected, because it does this:
/* Some types (eg GstElementState in GStreamer 0.8) has flags with 0 values,
* we're just ignore them for now otherwise they'll always show up
*/
if (flags_class->values[i].value == 0)
continue;
Adding a zero-valued member to each set of flags is considered best-practice in modern GLib code for more self-documenting C code (e.g. the enums in Gio
have always had those), and in GLib 2.73.x I added a zero-valued member to most of the flags in GLib that didn't already have one. The steps to reproduce that I quoted above use FileFlags
which has had a zero-valued member for a long time, and AsciiType
which still doesn't, even in 2.73.x (I didn't add one because nobody was quite sure why GLib.AsciiType
is even part of the public API).