On Wed, Jun 13, 2012 at 6:13 PM, John Ehresman <[email protected]> wrote: > > In Python 2, leaving the tp_hash slot set to NULL will result in the > PyObject* address being used for hash and equality if the compare slots are > also NULL which is what I think we want. This may be different in Python > 3.
That's what's happening in the hash function I sent, but there's a little assertion logic before the return. On further reflection, the reinterpret_cast<SbkObject*>(pyObj) was unnecessary since we're just returning the address, so I've removed that in this patch. 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. 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? > >>> hash(QtCore.QObject()) == hash(QtCore.QObject()) >> True >> > > That's fine -- equivalent hash values just mean that the 2 might be equal, > but you can't compare the two with == since they don't exist at the same > time. I agree, I just thought it was interesting and should probably be documented somewhere because it might surprise somebody. Nathan
hash.patch
Description: Binary data
_______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
