On Mon, Mar 24, 2008 at 10:30 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On Sat, Mar 22, 2008 at 3:04 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote: > ... > > On the other hand, all this gymnastic is done to allow receivers which > > do not conform to the full API of a signal (i.e., does not accept all > > signal arguments). What is the real reason behind this? Signal > > "extensibility"? > > Yeah, that's the idea. We're trying to keep some backwards > compatibility, and the existing system provides that argument > matching. Even some existing signal handlers in Django rely on it. > > Even so, it may be worth dropping. Numbers soon.
I am sure you already know it, but let me point out that this backward-incompatibility would be very easy to fix, just adding a **kwargs formal argument to every signal receiver. It seems like the idiomatic way to have "extensible" method signatures. Then, all the machinery messing with co_code would dissapear. As a side effect, the non-descriptor implementation of method saferefs could use curry(), for full compatibility with the default saferef implementation. -- Leo Soto M. http://blog.leosoto.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
