[Numpy-discussion] Speeding up wxPython/numarray

[Todd Miller]

On Thu, 2004-07-01 at 14:51, Tim Hochberg wrote:
> Todd Miller wrote:
> 
> >On Wed, 2004-06-30 at 19:00, Tim Hochberg wrote: 
> >  
> >
> >>>>
> >>>>        
> >>>>
> >>>FYI, the issue with tp_dealloc may have to do with which mode Python is
> >>>compiled in, --with-pydebug, or not.  One approach which seems like it
> >>>ought to work (just thought of this!) is to add an extra reference in C
> >>>to the NumArray instance __dict__ (from NumArray.__init__ and stashed
> >>>via a new attribute in the PyArrayObject struct) and then DECREF it as
> >>>the last part of the tp_dealloc.  
> >>> 
> >>>
> >>>      
> >>>
> >>That sounds promising.
> >>    
> >>
> > <>
> > I looked at this some, and while INCREFing __dict__ maybe the right
> > idea, I forgot that there *is no* Python NumArray.__init__ anymore.
> >
> > So the INCREF needs to be done in C without doing any getattrs; this
> > seems to mean calling a private _PyObject_GetDictPtr function to get a
> > pointer to the __dict__ slot which can be dereferenced to get the
> > __dict__.
> 
> Might there be a simpler way? Since you're putting an extra attribute on 
> the PyArrayObject structure anyway, wouldn't it be possible to just 
> stash _shadows there instead of the reference to the dictionary? 

_shadows is already in the struct.  The root problem (I recall) is not
the loss of self->_shadows, it's the loss self->__dict__ before self can
be copied onto self->_shadows.  The cause of the problem appeared to me
to be the tear down order of self:  the NumArray part appeared to be
torn down before the _numarray part, and the tp_dealloc needs to do a
Python callback where a half destructed object just won't do.  
 
To really know what the problem is,  I need to stick tp_dealloc back in
and see what breaks.  I'm pretty sure the problem was a missing instance
__dict__,  but my memory is quite fallable.

Todd