I did, I did ate a Zombie
From Ronald Oussoren to me (+ pyobjcdev and pythonmac-sig):
I haven't look at your example just yet, will do that later on. I'm
happy you took the time to create a small program that demonstrates
the problem you're seeing, that makes is so much easier to search the
problem.
> What did I learn from this:
>
> 1. Try to use cocoa objects instead of python objects in code that
> uses bindings; pay special attention to collections (lists, etc.).
> At least this *seems* safer because a python object being
> referenced from cocoa is probably more likely to cause problems
> than a cocoa object controlled from python. (?) Then again, it's
> pretty stupid to generalize from one experience...
Using Cocoa datastructures instead of python ones when KVO is
involved is always a good idea. Python doesn't have enough hooks to
allow reliable interception __setitem__. We could (but don't)
get 95% of the way by using the same class-swiffling technique as
used by the ObjC runtime, but could never go all the way.
> 2. GDB is very useful for debugging pyobjc.
> 3. There are a lot of nice pyobjc debugging features, but you have
> to turn them on (See my example project referenced above).
>
> Things I want to know:
> 1. Is there a way, when one gets the memory address of a pyobjc
> proxy object (Like OC_PythonArray) from gdb to figure out which
> python object it's proxying?
The PyObject* is stored as the instance variable 'value' on the proxy
object.
> 2. Is there a way to get the python object from a memory address?
You mean like "(PyObject*)0xDEADBEEF"?
> 3. Is there a reliable way to get (in gdb or pdb) the "Python List
> Object at 0x03423blahblahblah information from the python object
> being proxied
> 4. Can I compile pyobjc with debugging symbols? GDB without them
> hurts my brain.
PyObjC is compiled with debugging symbols by default. Py2app strips
debugging symbols, unless you build with the -A flag.
Ronald