

Aren't Django signals a little like COMEFROM? - teilo
http://uswaretech.com/blog/2009/07/arent-django-signals-a-little-like-comefrom/

======
ubernostrum
I've always just looked at them the way I look at any other event-based hooks
-- they're a way to say "when this thing happens, I want to know about it and
run some code".

Some programming languages even have this built in :)

~~~
shabda
But doesn't it lead itself to "Action at distance" anti pattern?

Like everyone else, we use django-regsitration a lot. Here in your code,
[http://bitbucket.org/ubernostrum/django-
registration/src/tip...](http://bitbucket.org/ubernostrum/django-
registration/src/tip/registration/models.py) you send a custom signal. Now any
one can break the normal flow of control and call control _from any where in
the project to anywhere in the project_.

~~~
thedz
Signals defines a fairly concise interface for interacting with events.

You're not "stealing" control from the loop. Rather, think of it more as
listening and attaching something to an event.

For me, it helps to think of signals less as interrupts in a traditional
program loop, but as something more akin to events in event-driven
environments.

------
Zak
It's better because it doesn't require messing around with, or even being
aware of the internals of the code it's being connected to. It's actually a
lot like a Common Lisp :before method, which I've found really bloody useful
on a few occasions.

~~~
mahmud
CL's customizable generic dispatch is just more than :before :-) the whole
thing is just tasty.

~~~
Zak
Indeed. If I ever design a general-purpose language, you can bet on it having
something of that sort.

------
pistoriusp
I think it's fine to say that you don't like signals. But I wouldn't do so
without proposing a better alternative.

------
Confusion
No they aren't. They are an implementation of the template method pattern,
perhaps with some cross polination from an observer pattern.

