Couldn't we move this discussion to the ticket on Django's Trac? http://code.djangoproject.com/ticket/9015
On Sep 12, 1:01 pm, zvoase <[EMAIL PROTECTED]> wrote: > I think the principle of least surprise applies here. It would be very > easy just to implement __call__ as a decorator, but by the same token, > the signal needs to be used from both ends, and the addition of a > __call__ method may confuse some people. As with most problems in > programming, we just end up discussing the name :) > IMHO, I think the removal of ambiguity is worth the extra 8 > characters. If we make a decision (by informal vote), then I'll just > go ahead and implement it, and then we just need someone to commit to > SVN. > > Regards, > Zack > > On Sep 11, 10:44 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > > > On Sep 11, 2008, at 21:19, Justin Fagnani wrote: > > > > I just got a chance to look at this, and I like it, but have one > > > suggestion. From a usage standpoint, wouldn't it be simpler to have > > > the decorator just be the signal name, like @pre_save? I can't see any > > > situation where you'd use a decorator for anything but connecting, so > > > the ".connect" part just seems unnecessary. > > > I just sat using the dispatcher from Django in a project of mine, and > > was stunned at > > __call__ not being *send*. So no, no __call__ decorator. > > > -- Ludvig --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
