ping.

On Tuesday 30 August 2011 14:50:11 Hugo Parente Lima wrote:
> On Monday 15 August 2011 09:07:50 [email protected] wrote:
> > Thanks! Looking pretty good already - I'm assigning it PSEP 106
> > (should've done it earlier already). I took the liberty of adding the
> > post history and updating the discussion section for you. The latest
> > version is here:
> > 
> > http://www.pyside.org/docs/pseps/psep-0106.html
> > 
> > 
> > Few comments still below.
> > 
> > > ``wrapInstance(address, type)``
> > > 
> > >     Creates a Python wrapper for a C++ object instantiated at a given
> > >
> > >memory
> > >
> > >     address - the returned object type will be the same given by the
> > >
> > >user.
> > >
> > >     The type must be a Shiboken type, the C++ object will not be
> > >     destroyed when the returned Python object reach zero references.
> > >     
> > >     If the address is invalid or doesn't point to a C++ object of given
> > >
> > >type
> > >
> > >     the behavior is undefined.
> 
> Ok, I didn't had seen this part of email before...
> 
> > Here, I am slightly bothered by the last paragraph. I am assuming that
> > when given an invalid address, this operation might indeed result in a
> > segfault or a very broken object. Is it possible to do any kind of
> > testing for the pointer validity? Perhaps not? If so, could it be more
> > explicitly stated that an invalid pointer will very likely result in a
> > segfault or, well, undefined behaviour.
> 
> It's impossible to check if the pointer is valid, it can e.g. point to a
> valid memory address but not to an object of the same type specified by
> the user, so the best we can promise for such low level function is an
> undefined behavior that must be read as "If it wont crash it's your luck
> day.", undefined behavior is a bit of C++ism and maybe this term isn't
> used very often on Python world, however I have no suggestion for this
> paragraph but accept suggestions.
> 
> > > ``wasCreatedByPython(obj)``
> > > 
> > >     Returns true if the given Python object was created by Python.
> > 
> > Wouldn't this be more consistent if it was just "isCreatedByPython"? At
> > least in Qt there are no methods starting with "was", AFAIK.
> 
> Yes it has:
> 
> QProgressDialog::wasCanceled and the wasHeld() from QML MouseEvent element.
> 
> But I guess they are outlaws in Qt, and reading
> http://doc.qt.nokia.com/qq/qq13-apis.html raised a question of:
> 
> isCreatedByPython(obj) vs createdByPython(obj)
> 
> > How about the counterparts for these sip methods:
> > 
> > 
> > isDeleted
> 
> This is equivalent to the isValid()
> 
> > setDeleted
> 
> I didn't find a valid use case for it, as it's not worth implement things
> without use cases I didn't added it when reviewing the sip API, but I could
> add it if someone have a valid one.
> 
> > __version__
> > __version_info__
> 
> My only doubt is if the shiboken module will have it's own version
> numbering or if it will follow the version of the whole shiboken package.
> 
> > Also the transferto and transferback sound like they could be really
> > useful for debugging purposes (although I hate the names).
> 
> I never needed to do such thing in Python, just on C++ binding code, this
> is why I didn't find a use case for this functions, for debugging purposes
> is useful to known who owns the object, but we already have a function to
> do this.
> 
> > So, I propose adding the above methods to the PSEP as well.
> 
> I think is better to find use cases for the functions without one before
> just adding them to the module:
> 
> setDeleted
> transferTo
> transferBack
> 
> I want also to add that we can't expose to much of libshiboken internals or
> it will be very hard to do internal changes in the future without break
> the ABI.
> 
> > Cheers,
> > 
> > ma.

-- 
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
PySide mailing list
[email protected]
http://lists.pyside.org/listinfo/pyside

Reply via email to