There are currently a handful of virtual function which are intended to return a new object but are marked as (transfer none). This causes problems because language bindings always sink newly created objects. Marshaling of the object from the language binding as a return value for a vfunc will then return a bad object because the sunk object is destroyed along with the language bindings wrapper (as the wrapper owns it). For example:

class ToolMenuAction(Gtk.Action):
    def do_create_tool_item(self):
        return Gtk.MenuToolButton()

APIs with virtual functions returning new objects should therefor only be marked as (transfer full). Doing this to the existing vfuncs would obviously cause breakage. This is a proposal to test the waters and see if the technique of adding alternate vfuncs for language binding support is acceptable.

There are a few alternative ways to fix the problem:
1. Force users of language bindings to use workarounds. This also adds extra support when they run into the problem and file ticket/ask questions.
2. Add hacks to language bindings themself. This might be possible but it is tricky and would need to be done to all language bindings.

The following is a list of problematic virtual functions for language bindings:

Gtk.Action.create_menu
Gtk.Action.create_menu_item
Gtk.Action.create_tool_item
Gtk.PrintOperation.create_custom_widget
Gtk.PrintOperation.create-custom-widget (signal)
Gladeui.EditorProperty.create_input
Gladeui.BaseEditor.build_child?
Gladeui.BaseEditor.build-child (signal)