Idea

[abdul azeez]

Pls can we make django come with django reest framework settings when you 
start a project

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b91e5471-23d3-41e2-b5c5-e1f860739fe0n%40googlegroups.com.

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

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

Re: Feature request : Load signals automatically

['Adam Johnson' via Django developers (Contributions to Django itself)]

I've replied on the forum.

On Tue, 14 Sept 2021 at 13:21, Roxane Bellot 
wrote:

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

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1%2B-MT4UXH5gAh6fPq1GuGjvC2gmU22VBrbXWONXKquGg%40mail.gmail.com.

Re: Feature request : Load signals automatically

[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.



> On 14 Sep 2021, at 17:37, 'Adam Johnson' via Django developers (Contributions 
> to Django itself)  wrote:
> 
> I've replied on the forum.
> 
> On Tue, 14 Sept 2021 at 13:21, Roxane Bellot  > wrote:
> 
> 
> 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
> 
> 
> -- 
> 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-developers+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAAvJ%2BFzx%3DFZ01BvBhEtH8SOZQA3imM4q3j1FNA7EF6ec1BKrPA%40mail.gmail.com
>  
> .
> 
> -- 
> 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-developers+unsubscr...@googlegroups.com 
> 

Re: Feature request : Load signals automatically

[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.
On Tuesday, September 14, 2021 at 5:41:30 PM UTC-4 Aymeric Augustin wrote:

> 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.
>
>
>
> On 14 Sep 2021, at 17:37, 'Adam Johnson' via Django developers 
> (Contributions to Django itself)  wrote:
>
> I've replied on the forum.
>
> On Tue, 14 Sept 2021 at 13:21, Roxane Bellot  wrote:
>
>>
>>
>> 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 ho