Re: [Pyobjc-dev] Exceptions on calling super

[Dirk S. <dir...@ma...>]

>> We recently moved our app from PyObjC 1.4 to 2.2 and now get a lot of
>> exceptions like this:
>>
>> TypeError??: super(type, obj): obj must be an instance or subtype of
>> type
>>
>> These happen in any Python subclass of a Cocoa superclass, but only
>> occasionally.  I'm not completely clear how to reproduce the issue,
>> but it only happens when we override an initializer and have a call  
>> to:
>>
>> super(classNameOfOurSubClass, self).init() # or any other  
>> initializer.
>>
>> Does anyone have a clue what might be going on?
>
> That message pretty clearly means that a classic class is getting
> injected somehow.  Consider this::
>
>    class C:
>        def foo(self):
>            super(C, self)
>
>    C().foo()
>
> Which version of Python?


Thanks for your reply :)

We're using Python 2.5.4 and we don't have classic classes anywhere in  
our app.

The error message I get from the example you wrote is also different  
from the one we're getting..

TypeError: super() argument 1 must be type, not classobj

The one I get seems to explicitely state that the second argument is  
not the type or a subtype of the first argument, yet the one I get  
when I run your example just tells me that the second type can't be  
'the' old-style classobj.

To get our app to stop crashing on this, I'll replace e.g.

class SFWindow(NSWindow):
     def initWithContentRect_styleMask_backing_defer_(self,  
contentRect, styleMask, backing, defer):
         self = super(SFWindow,  
self).initWithContentRect_styleMask_backing_defer_(contentRect,  
styleMask, backing, defer)
         if self:
             pass # do stuff
         return self

with:

class SFWindow(NSWindow):
     def initWithContentRect_styleMask_backing_defer_(self,  
contentRect, styleMask, backing, defer):
         self =  
NSWindow.initWithContentRect_styleMask_backing_defer_(self,  
contentRect, styleMask, backing, defer)
         if self:
             pass # do stuff
         return self
	
for now.  I'm not planning on changing the superclasses of any of  
these classes anyway, so the extra burden of maintaining this code is  
well worth getting rid of these occasional crashes.

Still very weird that this happens, I've tried to isolate the issue to  
a particular situation, but all my efforts so far have failed and I  
don't have time now to do more research.  I'll post again here if/when  
I've figured out the exact regression of this problem.

- Dirk