[PySide] Bug with new hash table feature

[John Ehresman]

On 6/14/12 11:13 AM, Nathan Smith wrote:
> Looking at shiboken/cppgenerator.cpp, tp_compare is always set to 0 and
> tp_richcompare is set to the wrapped class' overloaded operator== if it
> exists, or 0 if it doesn't, so I /think/ that's ok.

What I've done locally is just set tp_hash to NULL, which is what was 
happening before the commit at 
http://qt.gitorious.org/pyside/shiboken/commit/54cce10fa8a9942450c9e1a9d9a9d2a1b688f243 
  I did this by commenting out lines 3388-3389 in cppgenerator.cpp. 
Hashes for QObject derived objects worked before that, at least in Python 2.

> The unit test I have uses shiboken.invalidate because shiboken.delete
> surprisingly leads to segfault when deleting a HandleHolder object
> (works fine with a QObject), but that's a different bug.  I also found a
> segfault bug when calling shiboken.dump on deleted objects for which I
> plan to submit a bug and patch.

Thanks.

>     The class in the bug report is QListWidgetItem, which isn't derived
>     from QObject so there's no destroyed signal emitted when it's deleted.
>
> I'm not following.  What's the relevance of the destroyed signal to the
> hash function?

It may not be relevant, but one of the real complications of wrapping Qt 
is the lack of notification when non-QObject objects are destroyed. 
Because of this, you can't mark PyObject* wrappers as invalid when the 
C++ object is destroyed.  I think the Q*Item wrappers may essentially be 
temporary objects so you may get more than one PyObject* wrappers for a 
given C++ object, but I'm really not sure.  I just know that it's 
something to be aware of.

John