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 _______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
