On Thursday 11 August 2011 11:13:57 [email protected] wrote: > On 5 Aug 2011, at 22:57, ext Hugo Parente Lima wrote: > > As discussed in previous threads, here is my PSEP proposal for shiboken > > helper module. > > > > Waiting for comments. > > Hi, sorry for the delay. Here's my initial round. > > > PSEP: XXXX > > Title: Shiboken helper module > > Version: $Revision$ > > Last-Modified: $Date$ > > Author: Hugo Parente Lima <[email protected]> > > Status: Draft > > Type: Standards Track > > Content-Type: text/x-rst > > Created: 02-Aug-2011 > > Post-History: > > > > .. |maya| unicode:: Maya U+2122 > > > > Abstract > > ======== > > > > This PSEP describes a new module to access internal information related > > to our binding technology. Access to this internal information is > > required to e.g.: integrate PySide with Qt based programs that offer > > Python scripting like Maya or just for debug purposes. > > > > Rationale > > ========= > > > The Python module named "shiboken", will offer the following functions: > Comparing at PyQt's "sip" module, the proposal appears to provide quite > limited functionality. Assuming that all the different methods have been > added to "sip" due to some good reasons, wouldn't similar methods (where > applicable) become useful in "shiboken" as well. Hence, I'd propose going > through the "sip" module methods and picking any relevant methods to > "shiboken" as well.
I prefer start with a minimal set of functions then adding functions when needed/requested, i.e. when we get a good use case justifying the implementation. > Of course, since the implementation is different and code compatibility is > probably not a realistic goal (or is it?), I would also fix the method > naming of "sip" and review the API as well. Compatibility wasn't in my mind at first, but it's easy to do, IMO the sip names are very ugly, so better to achieve compatibility by creating function aliases. > In bug 902, Thomas proposed the underscore naming scheme. I agree it looks > cleaner than camel case, but perhaps we should still stick to camel case > to have more consistency with the rest of the PySide modules? In my > opinion, we definitely should not pick "sip"'s justwriteeverythingtogether > naming scheme. :-) I vote for camel case to have consistency with PySide naming scheme, despite of this there's no technical issues in being camel case or not. > > * isValid(obj) > > * wrapInstance(type, address) > > * hasOwnership(obj) > > * objectInfo(obj) > > > > More functions can be added in future PSEPs if needed. > > > > Some function description refer to "Shiboken based objects", wich means > > Python objects instances of any Python Type created using Shiboken. > > > > ``isValid(obj)`` > > > > Given a Python object, returns True if the object methods can be > > called without an exception being thrown. A Python wrapper becomes > > invalid when the underlying C++ object is destroyed or unreachable. > > Maybe call it isValidObject instead? Or isValidPythonObject? isValid is a > bit vague to me. But maybe it's just me? As there's no way to pass a non-python object to this function, isValidPythonObject is a bit redundant IMO. > > > ``wrapInstance(type, address)`` > > > > 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. > > > > ``hasOwnership(obj)`` > > > > Given a Python object, returns True if Python is responsible for > > deleting the underlying C++ object, False otherwise. > > > > If the object was not a Shiboken based object, a TypeError should be > > throw. > > Who has ownership? I mean, the name doesn't really describe the > functionality. sip calls the same thing "ispyowned". There, the return > values make more sense, but the name is quite ugly (shouldn't use > abbreviations if possible to avoid). > > isOwnedByPython? > ownedByPython? > isPythonOwned? I agree this name is confusing, I replicated it from Shiboken C++ API, I vote for "isPythonOwned" or "isOwnedByPython" to stick with Qt naming rules. > Or for Python crackers: > > isPythonPwned :-) > > > ``objectInfo(obj)`` > > > > Returns a string with implementation defined information about the > > object, this method should be used **only** for debug purposes by > > developers creating their own bindings as this PSEP doesn't offer > > any guarantee that the string format will be the same across > > different versions. > > > > If the object was not a Shiboken based object, a TypeError should be > > throw. > > Alternatively, we could return a NamedTuple which would include all the > information returned by the is* methods? That would provide the same > information but would also be useful for programmatic purposes. This function return many private things that aren't exposed by Shiboken API and shouldn't be exposed, I added it just because many times debugging shiboken we (binding developers) need a easy way to write just a "print" in python code and get know info about the internal state of an object, including private things that are useless for Python developers. Adding methods to return those internal things means adding functions to libshiboken to expose those internal things and this isn't desirable at all because those internal things can change/disappear from different versions of Shiboken without affect binary compatibility if they stay hidden. But... we could create a function o libshiboken that return a string and the function on shiboken module parses this string and returns the dict, although this will reduce the easiness of debug that was the main inspiration for this function: "write just a print to and get some info to help debugging". BTW, besides "wrapInstance" function none of those functions were meant to be used in non-debug scenarios. > > Discussion > > ========== > > > > Carlo Giesa wanted to do some integration of PySide with |maya| [#maya]_ > > and noticed that PySide doesn't have anything equivalent to PyQt4 > > ``sip.wrapinstance()``. > > > > David MartÃnez Martà filed a feature [#bug536]_ request for a function to > > return True or False if an object still valid or not. > > > > Thomas Pearl filed feature requests [#bug902]_ summarizing some functions > > that would appear in a helper module. > > > > References > > ========== > > > > .. [#bug536] `Bug 536 <http://bugs.pyside.org/show_bug.cgi?id=536>`_ - > > Add property to QObject that exposes is C++ reference is still valid. .. > > [#bug902] `Bug 902 <http://bugs.pyside.org/show_bug.cgi?id=902>`_ - > > Expose Shiboken functionality through a Python module. .. [#maya] A 3D > > Animation, Visual Effects & Compositing Software - > > http://usa.autodesk.com/maya/ > > > > Copyright > > ========= > > > > This document has been placed in the public domain. > > > > > > > > .. > > > > Local Variables: > > mode: indented-text > > indent-tabs-mode: nil > > sentence-end-double-space: t > > fill-column: 70 > > coding: utf-8 > > > End: > Cheers, > > ma. -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ PySide mailing list [email protected] http://lists.pyside.org/listinfo/pyside
