Python super() behavior not dependable

Question

For some reason, the super() method is not always behaving as expected, opting to return:

TypeError('super(type, obj): obj must be an instance or subtype of type)'

I understand what the error means. I do not understand why it is coming up as an error. Here's the snippet of code that is breaking. All objects in the system are new style objects.

What's really interesting is that this error does not always show up. I don't know what's causing it. The super() method in Retrieval is passing the Retrieval class, and then itself as an object, which is, as far as I'm aware,exactly how super() is supposed to be invoked.

Any thoughts at all?

In file DBConnection.py:

class DBAdminConnection(object):
    def __init__(self):
        self.user = DBUserConnection().user 
        self.submissions = DBSubmissionConnection()

In file Retrieval.py

class Retrieval(DBConnection.DBAdminConnection): 
    def __init__(self, username=None, password=None, unique_key=None):
        super(Retrieval,self).__init__()
        if username and password:
            self.username = username
            self.user.login(username,password, config.DATABASE)
            if self.user.error:
                raise UserLoginError(username)
        self.unique_key = unique_key

Eduardo Ivanec · Accepted Answer · 2012-03-15T15:44:42.413

57

Are you reloading modules somehow in the middle of things? If so, that may explain this error.

isinstance(self,DBAdminConnection) may become false after reloading modules because of the changes to memory references, apparently.

Edit: if you're running your web.py app under mod_wsgi, make sure you're disabling autoreload:

app = web.application(urls, globals(), autoreload=False)

edited Mar 15 '12 at 15:44

answered Mar 15 '12 at 15:15

Eduardo Ivanec

11,668
2
39
42

This is running through webpy. So that is a definite possibility. Especially since if I kill the app instance and respawn it, the problem goes away. Wow. Now the question becomes how the heck to fix it. – Thomas Thorogood Mar 15 '12 at 15:22
@TomThorogood: how are you running your app? Are you using mod_wsgi? – Eduardo Ivanec Mar 15 '12 at 15:38
I don't think I am doing that. I will add that now! I'm not using mod_wsgi. I'm using nginx with spawn-fcgi. I'll try disabling autoreload. Thanks so much! – Thomas Thorogood Mar 15 '12 at 16:55
I'm going to mark this as solved; everything you've suggested makes perfect sense and I believe the solution is the only one (unless there's a bug in webpy). – Thomas Thorogood Mar 15 '12 at 17:07
14

happened to me exactly as you said because I used the class in IPython with `%load_ext autoreload %autoreload 2` – P.R. Feb 18 '14 at 17:30

score 12 · Answer 2 · answered Aug 27 '13 at 21:59

12

If you are using reload() as part of your workflow, you apparently need to also use super(self.__class__, self).__init__ for inheritance initialization.

I suspect you will find this bug coincides with id(self.__class__) ==id(Retrieval) failing.

answered Aug 27 '13 at 21:59

Hal Meyers

161
1
2

8

`super(self.__class__, self)` is always wrong. It will become an infinite loop if you subclass any further. – Blckknght Jun 07 '14 at 14:07
1

What if you don't subclass any further, is that sometimes OK? – cce Dec 15 '14 at 05:38

score 1 · Answer 3 · answered Aug 20 '16 at 20:08

I just had the same problem, running my code in jupyter notebook. I was using reload, so I restarted my kernel to follow up on Eduardo Ivanec's response to try and see if this was the problem. Then my code broke. I discovered my problem was related to several layers of inheritance, where the bottom layer was defined above the second bottom layer in the module.

class MyClass1(object):
'''example class 1'''

class MyClass2(MyClass1):
'''example class 2'''
    def __init__(self):
    super(MyClass2, self).__init__()

class MyClass4(MyClass3):
'''example class 4 - no __init__ definition'''

class MyClass3(MyClass2):
'''example class 3 - no __init__ definition'''

When I moved MyClass4 underneath MyClass3, it fixed the problem.

This is probably a rookie mistake, so it probably won't resolve the cause of the original problem above, but I thought I would post in case there are other rookies out there, like me, who are making the same mistake.

(Apologies if my style is wrong, this is my first post on Stack Overflow. :))

score 1 · Answer 4 · answered Mar 03 '17 at 00:17

I had the same error then i noticed that i had duplicate class (my mistake) within the same file.py. Error disappeared when i renamed the second class A to class B

#Just some example below, not real code
class A (object):

    def fun(self):
        super(A, self).fun()

class A (object): ##This second class with same name (A) caused the error

   def some_fun(self,x,y):

Ethan Furman · Answer 5 · 2012-03-15T15:27:01.277

1

I'm not sure why the error is happening, but as an aid to debugging you could wrap the call to super in a try/except block and do a data dump when the exception is raised. Something like this:

class Retrieval(DBConnection.DBAdminConnection): 
    def __init__(self, username=None, password=None, unique_key=None):
        try:
            super(Retrieval,self).__init__()
        except TypeError, e:
            print "Failure initialising Retrieval --> self: %r"
            raise
        if username and password:
            self.username = username
            self.user.login(username,password, config.DATABASE)
            if self.user.error:
                raise UserLoginError(username)
        self.unique_key = unique_key

edited Mar 15 '12 at 15:27

answered Mar 15 '12 at 15:18

Ethan Furman

63,992
20
159
237

Did you mean that you're not sure? Because you got my hopes up for a moment. /grin – Thomas Thorogood Mar 15 '12 at 15:22
haha. no worries! Thanks for the thing. I have some debugging in place; i I was just cleaning up the code for SO. – Thomas Thorogood Mar 15 '12 at 15:35

Python super() behavior not dependable

5 Answers5

Linked