[PySide] Bug with new hash table feature
jpe at wingware.com
Thu Jun 14 17:40:44 CEST 2012
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
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.
> 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.
More information about the PySide