A slight amendment. I like your idea of moving registration and triggering into methods of the signal object itself, though that does then require that signals support a particular API, which currently isn't a requirement. Providing a base "Signal" class would, of course, help with this, but I like the potential of this, particular with regards to the order of execution issue.
The base Signal implementation could implement execution in an undefined order, for speed, and if a particular signal would benefit from having its listeners triggered in order, its trigger() (or execute() or whatever) method could be overriden to provide the necessary functionality. Or, depending on how the signal code works, it could override connect() instead, so that they're registered in the proper order. Either way, it's possible to implement on a per-signal basis, once the signals themselves are smarter. -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
