And yes, another problem is that the calling of method on the object created without .get() leads to crash. It should never crash, just raise an exception.

(In reply to Matěj Cepl from comment #0)
> In order to get working Gio.VolumeMonitor() I would assume that this Python
> script should do the job:
> 
> #!/usr/bin/env python
> from gi.repository import Gio
>  
> gmonitor = Gio.VolumeMonitor()
> gmonitor.get_connected_drives()
> 
> Unfortunately that leads to crash, because Gio.VolumeMonitor() actually
> doesn't create new Gio.VolumeMonitor object correctly, one needs to use
> Gio.VolumeMonitor().get().
> 
> It seems to me that the problem is missing (constructor) annotation on 
> https://github.com/GNOME/glib/blob/078dbda148a81af1b3a76fbda72f089b963087f1/
> gio/gunionvolumemonitor.c#L559

See also: bug 744690

The annotation is not the problem, and it would actually be wrong: g_volume_monitor_get() is not a constructor, it's a factory method which always returns the same instance for the whole duration of the application's life time.

You're supposed to use Gio.VolumeMonitor.get(), not the normal Python constructor form. What PyGObject can do is create an override for Gio so that trying to construct Gio.VolumeMonitor using the constructor's normal form will raise an exception.

(In reply to Matěj Cepl from comment #1)
> And yes, another problem is that the calling of method on the object created
> without .get() leads to crash. It should never crash, just raise an
> exception.

While it would be great if all errors at the C level automagically turned into Python exceptions, we cannot really do that. The C layer is binding-agnostic, and will abort() or segfault regardless. The closest thing we could do would be to check for missing methods because you created a GVolumeMonitor instance directly, but you'd still just get critical warnings in the program's output, not exceptions.

*** This bug has been marked as a duplicate of bug 744690 ***