On Wed, Dec 8, 2010 at 11:10 AM, Thomas Perl <[email protected]> wrote: > Hi again, > > 2010/12/8 deavid <[email protected]>: >> 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. > > I don't know if it's technically possible to do that, but assuming it > is, I'm again for naming it differently. "assert[something]" is > commonly used in JUnit-style test frameworks. A developer reading the > code could think that this is an assertion that is made *at the > current spot*. What about this for the same functionality: > > from PySide import debugging > > id = debugging.add_destroy_monitor(my_widget) > # ... > debugging.remove_destroy_monitor(id) > > I'm not sure if this is the best way to solve the problem, though. > Maybe it would be enough to set a global variable (e.g. > PySide.debugging.check_deleted = True) which will then print out a > warning message on the console when a QObject subclass is deleted > while still having an object in the Python world. Another option is to > provide real assertions that are checked on spot only and throw an > AssertionError when the assertion is not true, e.g.: > > debugging.assert_not_deleted(my_widget) > > You could then place this assertion wherever you want until you find > out where it really errors out. And you can leave it in the code > during development. >
-1 for object.isValid +1 for debugging.assert_not_deleted as it makes explicit this is a debugging check +20 for tracing the object invalidation. What about together with printing a message also having the option to call a user-defined callback with the invalidated object and additional info about where it happened, like nearest python frames, etc? -- Lauro Moura INdT - Instituto Nokia de Tecnologia _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
