CallbackRegistry should not silently drop duplicate callbacks #20210

Activity

1. anntzer

   added

   API: changesChanges to the public API, typically requiring deprecation.Changes to the public API, typically requiring deprecation.

   on May 12, 2021
2. timhoffm commented on May 13, 2021

   

   timhoffm

   on May 13, 2021

   Member

   More actions

   I agree that silently dropping the second connection request is bad style.

   What I don't understand is your choice of preference (preferred/less preferred). I don't where it could be useful to have duplicated connects. OTOH I can imagine scenarios in which certain actions that connect an event can happen multiple times, but you don't want multiple registrations. So requireing the user to track duplicates seems like an unnecessary burden. I'd Intuitively go for keep_duplicates (naming t.b.d.). But I'm not the event expert and maybe I'm missing something here.
3. anntzer commented on May 16, 2021

   

   anntzer

   on May 16, 2021

   ContributorAuthor

   More actions

   I guess defaulting to raising-on-duplicate is fine, but my point of view is that you shouldn't really rely on CallbackRegistry doing the dedupe for you anyways. For example, imagine (grossly simplified):

   def handler():
       # do whatever
   
   fig.canvas.mpl_connect("foo_event", lambda event: handler())  # indirectly through other functions
   fig.canvas.mpl_connect("foo_event", lambda event: handler())  # indirectly somewhere else

   (Assume that for whatever reason you indeed wanted handler to be called twice.) Some time later, you realize that your handler needs to take event as argument, so you write

   def handler(event):
       # do whatever
   
   fig.canvas.mpl_connect("foo_event", lambda event: handler(event))
   fig.canvas.mpl_connect("foo_event", lambda event: handler(event))

   and then you realize that you can rewrite this as

   def handler(event):
       # do whatever
   
   fig.canvas.mpl_connect("foo_event", handler)
   fig.canvas.mpl_connect("foo_event", handler)

   All of a sudden, the last version has different semantics, which I think is a bit unexpected... (IOW, I think one should normally be able to replace func by lambda *args, **kwargs: func(*args, **kwargs) without changing the semantics of a program.)

   OTOH I don't have a super strong opinion there either.
4. QuLogic commented on May 18, 2021

   

   QuLogic

   on May 18, 2021

   Member

   More actions

   In GTK and Qt, connecting a second time to an event simply connects again. In Tk, you can only bind once, it seems like.
5. tacaswell commented on Dec 20, 2023

   

   tacaswell

   on Dec 20, 2023

   Member

   More actions

   I'm of two minds on this.

   I can see why it would be useful to do this de-duplication ("please connect this function" "it already is! here is its cid") and as Elliott points out the GUI toolkits are split on this. On the other hand, I can see why "do exactly what I said" is nice.

   I would not block a PR to start this deprecation cycle.
6. timhoffm commented on Dec 21, 2023

   

   timhoffm

   on Dec 21, 2023

   Member

   More actions

   If we can’t guess what the desired behavior is, likely, there is no universal answer and making the behavior configurable is reasonable. Apart form the (limited) implementation effort, I don‘t see any downside with this.