Fwd: Feature request : Load signals automatically

[Roxane Bellot]

Hi guys !

First of all, i’m new here, so if this issue has already been discussed or if here is not the place to talk about it (I also opened a forum post) please don’t hesitate to tell me. Also, please be aware English is not my first language.

I would want to discuss about signals and how they are loaded in Django.

Very often, i create my signals.py, write my signal and wonder for a while why it does not work. Of course, the file is not imported and so never even read by python !
So i create an apps.py, on this template :

from django.apps import AppConfig


class CustomAppConfig(AppConfig):
    name = "app.subapp"

    def ready(self):
        import app.subapp.signals

I would like to sugest importing signals.py automatically at app loading (maybe django.apps.config.AppConfig.ready() ?)

Pros

• no more wandering for hours what is the problem here
• no more boilerplate apps.py everywhere

Cons

• file with signals would have to be named signals.py
• maybe some rely on the file being imported when they decided ? (don’t see a use case here, specially when loading signals does not equals activating them)

Alternatives

If loading (and so activating) signals is too mush of a change, maybe others solutions will fix my problem. For know, all I can think of :

• Log if a signals.py file is detected but the AppConfig is not overriden (but we would not know if imported elsewhere)
• Log how many signals are detected for the app (but from a dozen apps the log will be too heavy to be read)
• not really an alternative, but the loading could be conditionnal to a project-wide setting

i would like to know if this would benefits others (I think so) and if it is worthy of filing an Issue (as a developper I may find time to dev on it if needed)

Looking forward to reading from you,

Roxane Bellot

[Adam Johnson]

I've replied on the forum.

--
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 django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAAvJ%2BFzx%3DFZ01BvBhEtH8SOZQA3imM4q3j1FNA7EF6ec1BKrPA%40mail.gmail.com.

[Aymeric Augustin]

Hello,

I'd like to to chime in quickly as I'm responsible for this boilerplate (see this talk, slide 33).

This is really a question of convention vs. configuration. Django tends to prefer configuration over convention, because there's value is seeing what happens just when you read the code, especially when you read other people's code. Other frameworks take a different approach to this, perhaps because they care more about writing less code or because they focus more on the "single person team" use case.

As Adam points out in his reply on the forum, Django autoloads models, admins, and apps. Most Django users and maintainers love models and admins; hopefully they admit that apps solve a problem that needed solving. At the same time, many of them are also skeptical of signals, having witnessed excessive use of signals in projects, usually in the name of decoupling, and sometimes because the person writing the code didn't find any other way to break an import loop. (It's easy: import modules instead of objects, then reference all objects as mymodule.MyObject, and you're good.)

Signals result in inversion of control: you declare a function call in the callee rather than in the caller. This tends to make it more difficult to figure out what the code is doing. In my opinion, the only valid use case for signals is when the code sending the signal is provided by a third-party library that you don't control. If you have signals inside your project, I'd suggest refactoring them to good old function calls. Then perhaps you have fewer signals and don't feel such a need to autoload them. If you still have too many, Adam's suggestion works :-)

-- 

Aymeric.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1%2B-MT4UXH5gAh6fPq1GuGjvC2gmU22VBrbXWONXKquGg%40mail.gmail.com.

[cheeri...@gmail.com]

If you make signals autoload, you obscure what is happening. In the case of models and apps, they are so essential and tightly coupled to the framework itself that we can eschew the boilerplate for linking them together. The developer experience is almost universally better as a result. I don't believe the same is true for signals. Signals are not a feature core to the framework. I also suggest we avoiding debating their merits here though, that's a separate issue.

Wondering what's going on for hours is unfortunately an inevitable part of programming sometimes, and this is one of those times. If signals autoload, your experience will be better but you obscure what is really happening but everybody else working on a new Django project using them will have the same unfortunate experience of scouring the code to discover why SQL queries are being generated out of seemingly thin air in unrelated modules. Autoloading them will naturally raise coupling with the models as a whole, and I'm afraid of a future where new core Django code is pushed out with the expectation that signals are present.

There will always be use cases the defaults don't cover,  such as yours unfortunately. I hope you see my point of view.