pyobjc-dev

[Pyobjc-dev] Exceptions on calling super

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

Hi all,

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?

We're targetting Leopard and are currently still running on PyObjC  
2.2b6 (because getting later releases to actually build the app on  
Leopard has proven to be quite hard, and we're on a tight schedule, I  
haven't upgraded to something newer yet).

Thanks in advance!
- Dirk Stoop

Sofa

Re: [Pyobjc-dev] Exceptions on calling super

[Aahz <aa...@py...>]

On Thu, Sep 17, 2009, Dirk Stoop wrote:
> 
> 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?
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"I won't accept a model of the universe in which free will, omniscient
gods, and atheism are simultaneously true."  --M

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

Re: [Pyobjc-dev] Exceptions on calling super

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

On Sep 17, 2009, at 5:39 PM, Dirk Stoop wrote:

> We're targetting Leopard and are currently still running on PyObjC
> 2.2b6 (because getting later releases to actually build the app on
> Leopard has proven to be quite hard, and we're on a tight schedule, I
> haven't upgraded to something newer yet).

Oops, that should've been 2.2b2.

I just tried to install the latest and greatest from trunk on Leopard,  
so I can benefit from Ronald's latest fixes, but I'm getting errors on  
an unfound symbol, called: _PyType_Modified whenever I try to import  
objc.

Ronald responded to someone with the same or a similar issue over here  
a little while ago:

> http://www.gossamer-threads.com/lists/python/bugs/771198?do=post_view_flat#771198

Does anyone know what specific issues there might be with a Python  
installation that result in this "_PyType_Modified" to not be defined?  
-- I'm using a custom installed Python 2.5.4 on Leopard, because the  
standard installation has issues with building for PPC and Intel.

Thanks in advance,
- Dirk

Re: [Pyobjc-dev] Exceptions on calling super

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

More news from the working around front:

Apparently something in BridgeSupport changed in Snow Leopard, with  
the effect that you can no longer call unbound instance methods by  
passing in the instance as the first variable:

on Leopard:

> >>> NSObject.init()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: Missing argument: self


on Snow Leopard:

> >>> NSObject.init(someInstance)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: Need 0 arguments, got 1

Calling these the other way around works.

So quick heads up to anyone following this thread: My workaround was  
flawed.  Installing pyobjc from trunk on Python 2.6.2 now, as "import  
objc" seems to work on that. (no _PyType_Modified errors)

- Dirk

On Sep 21, 2009, at 12:46 PM, Dirk Stoop wrote:

> On Sep 17, 2009, at 5:39 PM, Dirk Stoop wrote:
>
>> We're targetting Leopard and are currently still running on PyObjC
>> 2.2b6 (because getting later releases to actually build the app on
>> Leopard has proven to be quite hard, and we're on a tight schedule, I
>> haven't upgraded to something newer yet).
>
> Oops, that should've been 2.2b2.
>
> I just tried to install the latest and greatest from trunk on Leopard,
> so I can benefit from Ronald's latest fixes, but I'm getting errors on
> an unfound symbol, called: _PyType_Modified whenever I try to import
> objc.
>
> Ronald responded to someone with the same or a similar issue over here
> a little while ago:
>
>> http://www.gossamer-threads.com/lists/python/bugs/771198?do=post_view_flat#771198
>
> Does anyone know what specific issues there might be with a Python
> installation that result in this "_PyType_Modified" to not be defined?
> -- I'm using a custom installed Python 2.5.4 on Leopard, because the  
> standard installation has issues with building for PPC and Intel.
>
> Thanks in advance,
> - Dirk
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Exceptions on calling super

[Ronald O. <ron...@ma...>]

Dirk,

I cannot reproduce this with Python 2.6 and PyObjC HEAD, or with /usr/ 
bin/python on SL with its version of PyObjC.

I've used the following scriptlet to test:

#BEGIN
from Cocoa import *

NSApplication.sharedApplication()

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

v = SFWindow.alloc().init()
# EOF

This prints "init" when run.

Ronald

On 20 Sep, 2009, at 13:16, Dirk Stoop wrote:

>>> 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
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Exceptions on calling super

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

Hi Ronald,

I recently moved our app to PyObjC HEAD / Python 2.6.2 (from the dmg  
installer from python.org) on Leopard and have not seen these  
exceptions since, so I'm also pretty sure the underlying issue is fixed.

Before making this move I've tried to isolate the issue but had no  
luck in figuring out a way to consistently reproduce it.  If I ever  
run into it again on a recent revision of PyObjC, I'll let you know.

thx,
- Dirk

On Sep 29, 2009, at 10:36 PM, Ronald Oussoren wrote:

> Dirk,
>
> I cannot reproduce this with Python 2.6 and PyObjC HEAD, or with / 
> usr/bin/python on SL with its version of PyObjC.
>
> I've used the following scriptlet to test:
>
> #BEGIN
> from Cocoa import *
>
> NSApplication.sharedApplication()
>
> class SFWindow(NSWindow):
>    def initWithContentRect_styleMask_backing_defer_(self,
>            contentRect, styleMask, backing, defer):
>        print "init"
>        self = super(SFWindow,  
> self).initWithContentRect_styleMask_backing_defer_(
>                contentRect,  styleMask, backing, defer)
>        if self:
>            pass # do stuff
>        return self
>
> v = SFWindow.alloc().init()
> # EOF
>
> This prints "init" when run.
>
> Ronald
>
> On 20 Sep, 2009, at 13:16, Dirk Stoop wrote:
>
>>>> 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
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF,  
>> CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market  
>> and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register  
>> now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>