On 18 Ago, 16:52, Michael Bayer 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.
