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 649662 - Annotate required constructor properties
Annotate required constructor properties
Product: gobject-introspection
Classification: Platform
Component: general
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
: 675648 744811 (view as bug list)
Depends on:
Blocks: 708060
Reported: 2011-05-07 14:40 UTC by Mathieu Bridon
Modified: 2018-02-08 12:06 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Mathieu Bridon 2011-05-07 14:40:14 UTC
I'm trying to create a new Gtk.Application instance, so I did the following:

$ python
Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) 
[GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import Gtk
Gtk-Message: Failed to load module "pk-gtk-module"
>>> Gtk.Application()
GLib-GIO:ERROR:gapplication.c:483:g_application_constructed: assertion failed: (application->priv->id != NULL)
Aborted (core dumped)

I'm not sure this is the proper way to instanciate an object, but if it's not, I would expect something like « __init__ takes 3 arguments, only 1 given », not a whole interpreter crash with a core dump. :)

Here is what I got with gdb:

  • #0 raise
    from /lib64/
  • #1 abort
    from /lib64/
  • #2 g_assertion_message
    from /lib64/
  • #3 g_assertion_message_expr
    from /lib64/
  • #4 ??
    from /lib64/
  • #5 g_object_newv
    from /lib64/
  • #6 ??
    from /usr/lib64/python2.7/site-packages/gobject/
  • #7 ??
    from /usr/lib64/python2.7/site-packages/gobject/
  • #8 ??
    from /usr/lib64/
  • #9 PyObject_Call
    from /usr/lib64/
  • #10 PyEval_EvalFrameEx
    from /usr/lib64/
  • #11 PyEval_EvalCodeEx
    from /usr/lib64/
  • #12 PyEval_EvalCode
    from /usr/lib64/
  • #13 ??
    from /usr/lib64/
  • #14 PyRun_FileExFlags
    from /usr/lib64/
  • #15 PyRun_SimpleFileExFlags
  • #16 Py_Main
    from /usr/lib64/
  • #17 __libc_start_main
    from /lib64/
  • #18 _start

Comment 1 Mathieu Bridon 2011-05-08 10:58:58 UTC
I should probably have mentioned it, but this is on Fedora 15, with the following:

I also get the exact same result with Python 3, in which case the packages are:
Comment 2 John Stowers 2011-05-08 11:02:59 UTC
You are missing the arguments to the constructor - see the GtkApplication API

For a complete example, see these two commits
Comment 3 Mathieu Bridon 2011-05-08 11:40:34 UTC
Thanks, I knew I was doing something wrong.

Just a little thing: normally, in Python, this is what I would expect when I'm wrong:
$ python3
Python 3.2 (r32:88445, Feb 21 2011, 21:11:06) 
[GCC 4.6.0 20110212 (Red Hat 4.6.0-0.7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Application:
...     def __init__(self, application_id, flags):
...         pass
>>> a = Application()
Traceback (most recent call last):
  • File "<stdin>", line 1 in <module>
TypeError: __init__() takes exactly 3 arguments (1 given)

Instead, here, the whole Python interpreter crashes. Perhaps this is still worth considering as a bug, to make the constructor fail more gracefully with a proper error message?

Thanks a lot anyway for the two examples. :)
Comment 4 Tomeu Vizoso 2011-05-09 06:52:57 UTC
(In reply to comment #3)
> Instead, here, the whole Python interpreter crashes. Perhaps this is still
worth considering as a bug, to make the constructor fail more gracefully with a
proper error message?

It's quite grave for developers using interpreted languages, but I'm not sure what we could do in PyGObject other than adding special cases for each of these, plus maintaining them, etc.

I see two clean approaches to this:

1. Consider buggy all classes that fail to be instantiated with g_object_new without construct-time arguments (and fix them). In this case, method calls on instances that are not properly initialized would fail later.

2. Add an annotation to mark those classes that are not safely constructed with g_object_new (without construct-time arguments) so bindings can raise an exception and users can go look at the available constructors.

Based on what we decide is best, this bug should be reopened and reassigned to Gtk+ (1) or to gobject-introspection (2). Maybe Mathieu wants to start a discussion in gtk-devel?
Comment 5 Mathieu Bridon 2011-05-09 07:15:51 UTC
(In reply to comment #4)
> Maybe Mathieu wants to start a
> discussion in gtk-devel?

Given my extremely long experience experience with Gtk (I never used Gtk in C, I only wrote a few lines of PyGtk2 code months ago to fix bugs in a few apps at work), and even less with gobject-introspection (I started my first PyGI application ever a couple of weeks ago, but I've only been working on it for a few hours since then), I'm pretty sure I am not the right person to start that discussion.

To tell you the truth, I am not even sure I really understood the 2 possible solutions you proposed. =)

I guess this is only a problem at the moment as the Python API is not really documented (or at least not on, and this kind of issues will almost completely disappear once this is done.
Comment 6 Tomeu Vizoso 2011-05-09 07:48:03 UTC
Moving to glib/gio in case Ryan or others have a better idea about what to do here.
Comment 7 johnp 2011-05-09 17:40:15 UTC
Perhaps we should have annotations for required constructor properties or annotations for default constructors where, if available, that is used instead of g_object_new.
Comment 8 Emmanuele Bassi (:ebassi) 2013-08-26 10:12:24 UTC
as a side note: both cases now work, as GApplication allows NULL strings for the application identifier.
Comment 9 Simon Feltman 2013-08-29 21:15:18 UTC
*** Bug 675648 has been marked as a duplicate of this bug. ***
Comment 10 Simon Feltman 2013-08-29 21:29:03 UTC
I just closed bug #675648 as a dup of this. There was the additional idea of adding a new GObject property flag instead of a GI annotation, something like: G_PARAM_CONSTRUCT_REQUIRED. I think this would be ideal because g_object_new could then error out when properties with this flag are not passed and fix this for all GI languages.

Generic attributes could also be used for the properties if we wanted to go the annotation route:

   * GBinding:source:
   * ...
   * Attributes: (GObject.Property contruct_required)

But then all binding layers would need to explicitly look for this and give an error accordingly.
Comment 11 André Klapper 2015-02-07 17:21:45 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 12 Simon Feltman 2015-05-23 19:17:49 UTC
*** Bug 744811 has been marked as a duplicate of this bug. ***
Comment 13 GNOME Infrastructure Team 2018-02-08 12:06:59 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: