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