On 6/12/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Keeping the API similar > to what it is (or at least, "routine" to port -- possible to do with a > reg-exp, say) would be worthwhile, since there is a lot of code in the > wild using the signal infrastructure.
This sums up my feelings perfectly. I'm all for cleaning (and speeding up) the signal infrastructure as long as the API doesn't change or at least only changes slightly. Looking over what Brian's written and the dispatch code, it looks like three small changes would let us simplify dispatching immensely: 1. Require the ``sender`` argument when connecting to a signal (i.e. don't allow ``Any`` sender any more). 2. Don't do any pattern matching on call signals; assume all listeners conform to the api ``listener(signal, sender, **kwargs)``. 3. Simplify ``robustApply`` accordingly (i.e. don't consider positional arguments). With those changes, the dynamic wrapping Brian's talking about would be much easier and none of the signal code I've written or seen would break (IIRC). A slightly more controversial change might be to drop ``robustApply`` entirely in favor of requiring listeners to *always* accept arbitrary kwargs. Frankly I'd be fine just telling people to always add ``**kwargs`` to their listeners; it's a trivial change to existing code. Thoughts? Jacob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
