event.remove failure

[sandro dentella]

Hi,

I started to play with events to port a library to sqla 0.7. I managed to use
the 'listen' function but I failed on 'remove'. Looking at the signatures
they seem to be just the same, but here is what I get:

  In [7]: event.listen(obj.__class__.title, 'set', listen_cb)

  In [8]: event.remove(obj.__class__.title, 'set', listen_cb)
  ---------------------------------------------------------------------------
  TypeError                                 Traceback (most recent call last)

  /home/misc/src/hg/py/sqlkit-pub/demo/sql/demo.py in <module>()
  ----> 1
    2
    3
    4
    5

  /misc/src/sqlalchemy/sqlalchemy/lib/sqlalchemy/event.pyc in remove(target, identifie
       69     """
       70     for evt_cls in _registrars[identifier]:
  ---> 71         for tgt in evt_cls._accept_with(target):
       72             tgt.dispatch._remove(identifier, tgt, fn, *args, **kw)
       73             return

  TypeError: 'InstrumentedAttribute' object is not iterable


Did I misundertand the syntax or what else?


TIA

sandro
*:-)

[Michael Bayer]

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.

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.

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 ?

--
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/SqqNPsbu8DsJ.
To post to this group, send email to sqlal...@googlegroups.com.
To unsubscribe from this group, send email to sqlalchemy+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.

[sandro dentella]

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
*:-)

[Michael Bayer]

On Aug 18, 2011, at 5:01 PM, sandro dentella wrote:

>
>
> 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.

ah OK so I'd build a system of indirection whereby you register a single event function with SQLAlchemy, then you have a simple "add/remove" system for that. The event listener would access the current list of GUI listeners, and that's the list you mutate.