[PySide] Bug with new hash table feature

[Hugo Parente Lima]

On Thursday, June 14, 2012 01:08:40 PM Nathan Smith wrote:
> Thanks.  The Shiboken module documentation at [2]
> http://www.pyside.org/docs/shiboken/shibokenmodule.html is missing
> invalidate, __version__ and __version_info__.  Also, the PSEP lists
> ownedByPython where the module implements it as isOwnedByPython (and adds
> wasCreatedByPython).  Is there a process for updating PSEPs?

Maybe the PSEP is out dated, there was a discussion about the API on the 
mailing list last year and the PSEP may not be modified to reflect the changes 
proposed in the mailing list.
 
> Nathan
> 
> On Thu, Jun 14, 2012 at 12:33 PM, Hugo Parente Lima <hugo.lima at openbossa.org
> > wrote:
> > 
> > On Wednesday, June 13, 2012 05:32:26 PM Nathan Smith wrote:
> > > We don't want to raise a RuntimeError when calling the hash function in
> > > Shiboken because of the very reason you stated.  Doing something that
> > > raises exceptions in the hash function will break any container that
> > > uses
> > > hashes (weak references, sets, dicts, weakref.WeakSet, probably many
> > 
> > more).
> > 
> > >  Returning default error values has a similar effect.
> > > 
> > > My most recent approach was to return the address of the shiboken
> > > object,
> > > which is address of the PyObject.  I tried this approach (I haven't
> > > submitted it yet) on the example you provided below, and it seems to
> > 
> > work.
> > 
> > >  I've been using it with my code for a few days now, and it's been
> > 
> > working
> > 
> > > well.
> > > 
> > > Note that using the address method has the drawback that two objects
> > > separated in time may have the same hash value because they may land at
> > 
> > the
> > 
> > > same memory address.  You can see this in the following test case:
> > > >>> hash(QtCore.QObject()) == hash(QtCore.QObject())
> > > 
> > > True
> > > 
> > > 
> > > The first QObject is created, the hash is taken of it, and then it is
> > > destroyed.  The reference count drops to 0, so the Shiboken handle is
> > > cleaned up.  A second QObject is created (at the same address as the
> > 
> > first
> > 
> > > QObject), the hash is taken of it, and then it is destroyed.  This could
> > 
> > be
> > 
> > > avoided if we kept a running counter of SbkObject instances and used the
> > > counter as the hash value (which I think is overkill).
> > > 
> > > Incidentally, what is the difference between shiboken.delete and
> > > shiboken.invalidate?  There don't appear to be any docstrings in the
> > > shiboken module and invalidate isn't in the online documentation.
> > 
> > The docs are on the PSEP[1] and on Shiboken docs[2].
> > 
> > delete really deletes the underlying C++ object then invalidate the Python
> > object, i.e. any use of this object will raise a exception.
> > 
> > invalidate only invalidates the Python object, causing it to raise an
> > exception when used.
> > 
> > [1] http://www.pyside.org/docs/pseps/psep-0106.html
> > [2] http://www.pyside.org/docs/shiboken/shibokenmodule.html
> > 
> > > Nathan
> > > 
> > > On Wed, Jun 13, 2012 at 3:45 PM, John Ehresman <jpe at wingware.com> wrote:
> > > > On 5/30/12 3:35 PM, John Ehresman wrote:
> > > >> Can we use the address of the Shiboken object as the hash value? 
> > > >> That
> > > >> 
> > > >>> remains valid so long as there are references to the object, even
> > 
> > after
> > 
> > > >>> the object itself has been deleted in C++ land.
> > > >> 
> > > >> This works if there can only be one wrapper at a time for a given
> > > >> QObject.  I don't know if this is the case.
> > > > 
> > > > I just ran into this bug and tried to apply the patch locally, but ran
> > > > into poblems.  If the address of the PyObject* can be used, I think
> > 
> > that
> > 
> > > > would be preferable.  Consider the following:
> > > >    o = QObject()
> > > >    d = {}
> > > >    d[o] = 1
> > > >    
> > > >    def on_destroy():
> > > >        d.pop(o)
> > > >    
> > > >    o.destroyed.connect(on_**destroy)
> > > >    shiboken.delete(o)
> > > > 
> > > > The pop in the destroy handler will fail with a RuntimeError and even
> > 
> > if
> > 
> > > > the RuntimeError is suppressed and a default hash value returned, the
> > > > entry
> > > > in the dictionary won't be found or removed.
> > > > 
> > > > John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/pyside/attachments/20120614/7e9302fe/attachment-0001.sig>