On Thu, Mar 19, 2009 at 2:43 PM, Zachary Voase wrote:
>
> I spoke about this on here a while ago, but seeing as the 1.1 feature
> freeze is looming, I thought it would be a good idea if I brought it
> up again.
>
> I think it's a good idea to have some support for using Python's
> decorator syntax
I spoke about this on here a while ago, but seeing as the 1.1 feature
freeze is looming, I thought it would be a good idea if I brought it
up again.
I think it's a good idea to have some support for using Python's
decorator syntax on signal receivers; seeing as Django's probably
going to switch t
I just wanted to check if there was a consensus on this; it would be
nice to get it into the Django 1.1 featureset.
Regards,
Zack
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
Oh, yeah, by the way, for those who haven't looked at the ticket, my
implementation changes the 'connect' method, so that it can be used in
the old way ("signal.connect(receiver)"), or as a decorator
("@signal.connect" with "def receiver").
The old 'connect' method is still used (by the new metho
I think the "signal.decorate" form is nicer, but the name has to show
that there is some sort of connection going on; if you want to know
why I think this is, take a look at "The Zen of Python". Basically,
it's explicit (you know it refers to *that* signal), it's the obvious
way to do it (seeing a
On Sep 12, 2008, at 13:01, zvoase 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.
On Sat, Sep 13, 2008 at 8:10 AM, zvoase <[EMAIL PROTECTED]> wrote:
> Couldn't we move this discussion to the ticket on Django's Trac?
Preferably not; it's far easier to keep track of a threaded discussion
here on the mailing list, as opposed to trying to follow it in the
ticket.
--
"Bureaucrat
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 s
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
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
On Thu, Sep 11, 2008 at 2:19 PM, Justin Fagnani
<[EMAIL PROTECTED]> wrote:
> This could be implemented easily by adding a __call__() method to Signal.
>
That's a win. Anyone against?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to th
Hey Zack,
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
I've created a ticket: http://code.djangoproject.com/ticket/9015
I've also uploaded a patch with the suggested changes.
Regards,
Zack
On Sep 10, 1:30 pm, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> Patch or ticket, please.
>
> On Sep 10, 2008, at 3:52, zvoase <[EMAIL PROTECTED]> wrote:
>
>
>
> > H
Patch or ticket, please.
On Sep 10, 2008, at 3:52, zvoase <[EMAIL PROTECTED]> wrote:
>
> Hi Django developers,
> Usually, signal receivers are defined as functions and then connected
> to a specific signal via a function call outside of the defined
> function. This can cause clutter, it violat
Hi Django developers,
Usually, signal receivers are defined as functions and then connected
to a specific signal via a function call outside of the defined
function. This can cause clutter, it violates DRY, and it is not very
Pythonic in style. Several examples of the current usage pattern are
inc
15 matches
Mail list logo
