On 18 Ago, 16:52, Michael Bayer <mike...@zzzcomputing.com> wrote: > remove() isn't implemented yet. While the simple operation you see below > would be fine for a single listener on a single target, the targets we have > which propagate to subclasses (mapper events, attribute events) would require > a more elaborate system that can revisit everywhere the event has been > propagated and remove it from there as well. > > this is why "remove" isn't published in the docs right now.
Thanks, I wasn't carefull enought to realize it was not in the docs. I guessed there was such a function and I found it, so I tried to use it... > In our own tests I use a hack to remove an entire set of listeners at once, > if this is a testing teardown scenario you're dealing with. No really I would need it in a different setup. I have many GTK widgets that show some data that are in a session and I need to update the GUI whenever the data change. > Otherwise, ad-hoc removal on a per operation basis ? I knew someone would > try it though damned if I could imagine what possible use there could be for > that. If this is the case here, care to entertain me ? Not sure what you mean exactly here, but if the point is: "why I want to use 'remove'". It's just that when I destroy the GUI widget that displays data I'd like to remove the listener to be sure no reference tries to keep my object in memory. As of now I see that callbacks are still called. sandro *:-) -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
