Hi :-) > I think it's a helpful tool during development. Such features are > misused if exposed in the "public" API, and if we have this isValid() > on the QObject, it could confuse developers looking for e.g. a > validation method of their entry box (which is not at all that this is > about, but the name might suggest that in a specific context without > any knowledge that this feature exists). > > My proposal: Add it as feature somewhere "outside" of the normal API > (e.g. PySide.debugging) like this: > > from PySide import debugging > > if debugging.qobject_deleted(my_widget): > print 'ohai deletion handling!' >
You're right; something like that will be more clear. > A good idea might be that this "debugging" module is only available > when PySide is built with the debug target, not in the release target > (again, to avoid usage of this in "normal" code). On the other hand, > when the module is already named "debugging", it could be built in the > release target as well, as its name already suggests "this is > something you only want to use during a debugging session". AFAIUI > this is nice for when somebody wants to figure out when an object gets > deleted during development, but it should never be used in production > code for day-to-day usage. Of course, the naming and structure is up > for discussion :) I think it will be a mistake to build only on debug releases, because it is useful to debug python application, not the pyside library. When you build a debug version of pyside is because you want to debug something in pyside, and that is not the case of this property. I believe this property will be useful to debug our python applications, to understand why some object has been destroyed. Because of that i think it should be built on debug and on release builds. In the conversation i had before in the IRC with hugopl ( http://dpaste.com/284241/ ) i was wondering about antoher option to help developers know where their objects get destroyed. When something gets destroyed and you don't know why, you will be searching which call did that and when. If destroying some object could produce an exception, would help a lot finding that function. Of course, raising exceptions for each object that gets destroyed doesn't makes any sense. But, for example, i could say: the object MyWidget can't be destroyed until some other object exists, or until i say that it can be destroyed. (i'm talking again about debugging a problem, not as a standard way of coding) That example could be: from PySide import debugging MyWidget = QFrame() debugging.assertDestroyed(MyWidget, False) # assert MyWidget is *NOT* destroyed (and will not) (...) # do something with MyWidget MyWidget.addWidget(....) # etc. # When we finish with it: debugging.assertDestroyed(MyWidget, None) # remove the previous assertion and let MyWidget be destroyed. If some function would try to destroy MyWidget PySide would raise an RunTime exception showing the problem. And then the traceback will give us the exact reason. It doesn't look very pretty, i know; and it's only for debugging purposes (i think that should be clear, no one should create a real application with that kind of stuff inside), but it is very useful. Think about it, in C/C++ we haven't that tool and we end looking the entire source code looking for some mistake, and could be very complicated to spot. These problems will be also on PySide where we are using functions that could delete objects. Having such a powerful tool will ease the task of tracking the problem source. _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
