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 351566 - super() calls do not work in __init__
super() calls do not work in __init__
Status: RESOLVED OBSOLETE
Product: pygobject
Classification: Bindings
Component: gobject
2.8.0
Other Linux
: Normal major
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
: 554443 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-08-15 23:36 UTC by Joe Wreschnig
Modified: 2012-04-21 14:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Joe Wreschnig 2006-08-15 23:36:41 UTC
The following code prints nothing:

---
import gtk

class WidgetMixin(object):
    def __init__(self):
        super(WidgetMixin, self).__init__()
        print "Called WidgetMixin.__init__."

class MixedInLabel(gtk.Label, WidgetMixin):
    def __init__(self):
        super(MixedInLabel, self).__init__()

if __name__ == "__main__":
    MixedInLabel()
---

When it should print "Called WidgetMixin.__init__".

This may come from a common misinterpretation of super (described at http://fuhm.net/super-harmful/):

"One big problem with 'super' is that it sounds like it will cause the superclass's copy of the method to be called. This is simply not the case, it causes the next method in the MRO to be called. People omit calls to super(...).__init__ if the only superclass is 'object', as, after all, object.__init__ doesn't do anything! However, this is very incorrect. Doing so will cause other classes' __init__ methods to not be called."

I am marking this major because it makes mixins near-useless for PyGTK, and certainly is not the behavior one expects calling super().
Comment 1 Johan (not receiving bugmail) Dahlin 2006-08-16 00:52:06 UTC

*** This bug has been marked as a duplicate of 315079 ***
Comment 2 Gustavo Carneiro 2006-08-16 10:39:11 UTC
This is a different bug, not a dup of bug 315079.  #315079 is a special case for do_xxx methods, this relates to tp_init and the need to chain to a parent class using MRO.  The two bugs have completely different solutions.
Comment 3 Gustavo Carneiro 2007-07-07 13:34:21 UTC
I was looking at this bug, but it is relatively difficult to fix:

  1. It requires going to pygobject_constructv and chaining to parent constructor using a real super object (using PySuper_Type.tp_new (...), calling __init__ method on it, passing the class as first argument, etc..)

  2. It requires that pygobject_constructv receives the python class as parameter, like in regular python code => API changes, code generator changes.

Personally I don't have time to fix this, but patches are welcome.
Comment 4 Paul Pogonyshev 2008-09-30 20:10:23 UTC
*** Bug 554443 has been marked as a duplicate of this bug. ***
Comment 5 Sebastian Pölsterl 2012-04-21 14:14:49 UTC
Thanks for taking the time to report this bug. However, this bug report applies to a PyGObject version that is too old and not supported anymore.
PyGObject developers are no longer working on static bindings, so unfortunately there will not be any bug fixes for the version this report applies to.

By upgrading to a newer version of PyGObject you could receive bug fixes and new functionality. Please feel free to reopen this bug if the problem still occurs with a newer version of PyGObject.