Hello, My experience with Django — and not just with inexperienced developers — is that signals are a footgun. I've seen them misused as workarounds for badly structured code and unclear dependency trees too often. I'm not eager to encourage their use.
Fundamentally, signals in Django allow a developer to declare a function call at the callee site instead of at the caller site. That provides a way for app developers to modify the behavior of libraries written by others, but not a very good one. "Signals as an API" have the drawbacks as "subclassing as an API", such as making it difficult to tell what happens just by following function calls in the code, and then some, for example : - managing exceptions: while signals give control back from the library to the app, they also create their own tiny area of inversion control where the signals framework manages execution of signal receivers ; you can either get all exceptions or ignore them all, but it's the library that makes this decision, not the app. - transactional behavior: as a consequence of the previous point, it's very hard to make guarantees about what the consistency of code that executed successfully or failed to execute when signals are involved. - execution order of receivers: I'm supposed to have rewritten app-loading in Django 1.7 to make it deterministic, but I still don't quite believe it's reasonable to rely on import order. - no encapsulation: even if encapsulation is merely a convention in Python, at least inheritance defines some boundaries on the behavior. I'd really prefer if Django encouraged people to support customizing forms through dependency injection, which in my opinion is the proper way to perform such customizations. It can be as simple as specifying a dotted Python path to a form class in settings if there's a desire to stay away from the factory pattern and minimise boilerplate setup code. I must be one of the more anti-signals people here — I could make the argument that signals aren't GOTOs, they're COMEFROMs with a straight face — so don't take may opinion as reflecting the consensus. It would be nice to know what other solutions you considered before proposing this one, though. Best regards, -- Aymeric. > On 6 Mar 2017, at 19:10, David Seddon <[email protected]> wrote: > > Hi all, > > One thing I've always found challenging with Django is to adjust the > functionality of forms from other apps. An example might be to add an extra > field to a login form provided by a third party module. > > What I end up doing is often overriding the urlconf, view and form class. > Or, worse, monkey patching the form class. > > A much nicer way to do this would be to add a few well chosen signals to > forms. > > Potential ones could be: > > - post_init > - post_clean > - post_save (for ModelForms) > > I'd be happy to do a pull request for this, but just wondered what people > think. > > David > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/d936a1d5-3f6e-4190-83c3-5cc31c8fbb4e%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/d936a1d5-3f6e-4190-83c3-5cc31c8fbb4e%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/F928DC5B-78AC-4755-95A5-2689D48953DA%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
