Sorry! On Aug 30, 2011, at 18:50, ext Hugo Parente Lima wrote:
> On Monday 15 August 2011 09:07:50 matti.p.ai...@nokia.com 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 Sorry that I didn't catch this earlier: the document structure is a bit lacking now. The "Rationale" section should be an introduction section, describing why the work described in the PSEP is needed. Then, there should be a separate section documenting the actual meat, as in your current Rationale. > 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. Then, how about: If the address is invalid or does not point to a C++ object of given type, use of the wrapped object may result in a segmentation fault or other undefined behaviour. > 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) Nice link. Reading that through, I think it would point us to "createdByPython". >> isDeleted > > This is equivalent to the isValid() OK! > >> 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. Debugging? I believe it could be conceivable that people face issues with the bindings and might want to tweak around before filing a bug report but are not willing to dive into regenerating the bindings again. > >> __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. I thought it would follow the shiboken package version numbers. >> 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. Again, Python-side debugging could be the usecase, but ... >> 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 ... if you insist they're not useful for that, better leave them off. > 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. Good point. Could you prepare a new version. Assuming no other comments are forthcoming, that version could then be submitted for core dev team's review and hopefully marked accepted soon. Cheers, ma. _______________________________________________ PySide mailing list PySide@lists.pyside.org http://lists.pyside.org/listinfo/pyside
