Re: For discussion: JSON-aware views for error responses

[Tobias Bengfort]

+1 from me.

On 14/04/2022 11.03, Ville Säävuori wrote:
And to be clear, I understand we already have middleware APIs and 
various settings to handle this but my point is that I think handling 
this in Django core (even as an optional setting or middleware) would be 
most useful and right way to do this for the community.


Can you provide some examples? I support the general idea, but having 
some concrete APIs to discuss might be helpful.


thanks
tobias

--
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/0cb96663-a937-e82f-8f50-43f279c14543%40posteo.de.

Re: For discussion: JSON-aware views for error responses

[Jacob Rief]

I encountered this problem many times myself, so I'm +1 for this proposal. 

– Jacob

-- 
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/639a72d1-ae5d-4bae-bd28-b3b5f1d2d955n%40googlegroups.com.

Re: Improvements to the startproject template

[Ian Foote]

I want to add that I think either proposed change here would be an
improvement and that I'd prefer not to see this idea die because of
bikeshedding over the best option.

Regards,
Ian

On Thu, 21 Apr 2022 at 19:21, ome chukwuemeka 
wrote:

> I think this is a good suggestion!
>
> On Thu, Apr 21, 2022, 7:08 PM Albert  wrote:
>
>> It is possible to do in current version of Django with two lines of code:
>>
>> mkdir my_project
>>
>> django-admin startproject config my_project
>>
>> I have been working for many companies that use Django and I have seen
>> that each ot them has their own structure of project.
>>
>> And usually project is created once per couple of months, so I don't see
>> advantages of changing project structure.
>>
>> Regards,
>>
>> Albert
>>
>> Temat: Re: Improvements to the startproject template
>>
>> As there are different preferences and some see the change as worse than
>> the default and there is already a way to change the template for
>> startproject, wouldn't it be easier to provide different templates and list
>> them in the documentation, so that they can be used with the --template
>> argument? With a short section about each template and the pros and the
>> cons, and for what kind of project one is better suited.
>>
>> Maybe the three top templates could be shipped directly with django, so
>> that users could choose one with --template=simple, --template=nested or
>> --template=config or something in that direction.
>> On Thursday, April 21, 2022 at 11:16:23 AM UTC+2 ator...@redhat.com
>> wrote:
>>
>>> I personally dislike Adam's suggestion and feel like it makes it worse
>>> than the current default, but to each their own.
>>>
>>> I do prefer the proposed solution of the config directory, I am working
>>> on two django projects in parallel and one follows the proposed config
>>> scheme and the other doesn't (uses the default) and I find the proposed
>>> config scheme more natural to use and navigate, so that's a +1 from me too
>>>
>>> On Thursday, April 21, 2022 at 5:10:06 AM UTC+2 pem...@gmail.com wrote:
>>>
 For what it's worth, this is the (general) layout I've used for the
 past 8+ years of my professional Django development.

 Arthur

 On Wed, 20 Apr 2022 at 15:22, Olivier Dalang 
 wrote:

> +1 for Adam's suggestion, I use it as well and like it very much.
>
> > root folder
> - manage.py
> - ...
> > myproject
> - __init__.py
> - settings.py
> - urls.py
> - ...
> > myapp
> - __init__.py
> - models.py
> - ...
>
> Pros:
> - everything is well namespaced under myproject (`myproject.settings`,
> quite straightforward)
> - makes it clear that `settings.py`, `urls.py`, etc. concern the
> project as a whole, and not just an app.
> - also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it
> clear that myapp is part of this project)
> - it leaves the root level for stuff like .gitignore, db.sqlite, etc,
> so the actual source stays clean from such files.
> - having a parent package allows (does not require) relative imports
> across modules of the same project, which more clearly conveys that such
> apps are tightly coupled
> - with manage.py still in the root folder, you don't need to cd into
> any folder to start working
>
> I use it all the time.
>
> Cheers,
>
> Olivier
>
>
>
>
> Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :
>
>> I prefer Adam's suggestion in the forum post as it lets you namespace
>> everything under your project name nicely and avoids package name
>> collisions, although it doesn't solve the problem of having two 
>> directories
>> with the same name by default.
>>
>> That said, either would be an improvement on what we have so I'm in
>> favour of either approach over doing nothing.
>>
>> Cheers,
>> Tom
>>
>> On Wed, 20 Apr 2022 at 16:49, John M 
>> wrote:
>>
>>> I do exactly this for every new Django project, so it's +1 from me
>>> as well.
>>>
>>> John
>>> On 20/04/2022 12:01, da...@springbourne-tech.com wrote:
>>>
>>> +1 for me - this would be really useful.
>>>
>>> On Monday, April 18, 2022 at 9:02:02 PM UTC+1 pyt...@ian.feete.org
>>> wrote:
>>>
 Hi Tim,

 This feels like a good idea to me.

 Regards,
 Ian

 On Mon, 18 Apr 2022 at 18:17, Tim Allen 
 wrote:

> Greetings, friends!
>
> I've issued a PR that makes two changes to the
> `startproject` template:
>
>- instead of putting configuration files such
>as `settings.py`, `wsgi.py`, and the
>root `urls.py` in `my_project/my_project`, they are created

Re: Stop QuerySet repr from executing queries

[Ian Foote]

I've been working on the Kolo debugging tool and as part of that I've also
run into this issue. Generating unexpected queries when monitoring a django
project was a nasty surprise.

In Kolo's case I was also able to work around it with a monkeypatch, but
not needing this would be a nice performance win.

I also want to point to a similar case in Django where I think the default
behaviour is more helpful - that of forms. Calling `str` on a form can
trigger form validation, but calling `repr` avoids this. I'd be in favour
of moving the current `__repr__` implementation for `QuerySet` into
`__str__` and having an implementation of `__repr__` guaranteed not to
generate extra queries.

Regards,
Ian

On Fri, 15 Apr 2022 at 16:03, 'Kevin Weaver' via Django developers
(Contributions to Django itself)  wrote:

> I know this thread is more than a year old, but I was just bitten by this
> as well. We use the Elastic APM Python agent
>  which, like Sentry, calls
> `repr()` on local variables that it sends as part of stack traces. We use 
> Django
> REST Framework  and had a
> serializer that looked something like this (fake) example:
>
> ```
> class AccountSerializer(ModelSerializer):
>   owner = PrimaryKeyRelatedField(queryset=User.objects.all())
>   days_since_joined = serializers.SerializerMethodField()
>
>   def get_days_since_joined(self, obj):
> try:
>   ...
> except Exception:
>   logger.exception(...)
> ```
>
> What happened was:
>
>1. We have several places in the application that return a paginated
>list of, say, 50 accounts, using this serializer.
>2. Someone introduced the log line to catch exceptions when
>calculating `days_since_joined`, which is called for each of the 50
>accounts returned on the page. Due to a bug, the exception was almost
>always raised.
>3. Each time the exception is raised, the Elastic APM Python agent
>generates a stack trace and calls `repr()` on local variables in each stack
>frame. One of those variables in the `get_days_since_joined` frame is the
>`AccountSerializer` object `self`, which includes the `owner` property.
>Calling `repr()` on the `owner` property evaluates the `User.objects.all()`
>QuerySet, which fetches the first 21 User objects from the database.
>4. We now had `SELECT ... FROM user LIMIT 21` being called in a loop
>50 times each time someone tries to load a page of accounts, suddenly
>consuming significantly more database CPU and slowing down the application
>considerably until queries start timing out.
>
> To prevent this from happening again, we ended up applying something very
> similar to the suggestions above as a monkey patch:
>
> ```
> orig = QuerySet.__repr__
>
> def __repr__(self):
>   if settings.DEBUG or self._result_cache:
> return orig(self)
>
>   return f"<{self.__class__.__name__} [not evaluated]>"
>
> QuerySet.__repr__ = __repr__
> ```
>
> If folks are willing to reconsider their positions on this issue, I am
> more than willing to do what is necessary to contribute this change
> upstream, so that others are not impacted by this in the future.
>
> Thank you,
>
> Kevin
>
> On Tuesday, March 23, 2021 at 9:02:39 AM UTC-4 Adam Johnson wrote:
>
>> Would James' suggestion of reusing the result cache in __repr__ have
>> solved your issue? I would like to see that first.
>>
>> I'm not against the DEBUG-only fetching but there hasn't been any
>> suggestion what to show instead that could be of use.
>>
>> One can also mitigate against bad queries particularly well by setting a
>> statement timeout at the database level (at least MySQL and PostgreSQL
>> support this), which most users will generally want at a scale where repr()
>> becomes a problem.
>>
>> On Tue, 23 Mar 2021 at 12:40, Joachim Jablon  wrote:
>>
>>> Just been bitten by that same bug (combination of Sentry, using a
>>> Queryset.as_manager() that creates an unfiltered queryset as a local
>>> variable in the stack, a create signal that errored provoking a stacktrace
>>> that contained the queryset, a table that is always filtered by a field,
>>> and sorted by another field and an index that behaves poorly without the
>>> aformentionned filter).
>>>
>>> So would a contribution that would avoid evaluating the uncached
>>> queryset on repr when DEBUG is False likely to be accepted ? If so, I'm
>>> ready to get my hands dirty :)
>>>
>>> Cheers !
>>>
>>> Le dimanche 7 mars 2021 à 00:54:56 UTC+1, mic...@turbosys.com.br a
>>> écrit :
>>>
 I agree with Matt on that. Avoiding executing the queries on production
 would be helpful!

 Let me share my case. I use django-rest-framework in a specific project
 and DRF has a feature: a serializer has a fancier string representation
 when printed. I was using a serializer with a queryset in a view that had
 an exception further, which caused the serializer to be 

Re: Improvements to the startproject template

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Tim,

Thanks for taking this on!

Needless to say, I'm all in favor of including a default 'users' app.
Adding one (as has long been recommended by the docs) is a task best
automated.

I've definitely had the "no the other folder" conversation more than enough
times myself. Personally I think I prefer the orderliness of nesting
everything under a single Python package that is the project name, but I'm
not sure how to do that and solve the "two folders with the same name"
problem. In any event, I support whatever the consensus is.

Cheers,
Tobias



On Mon, Apr 18, 2022, 1:17 PM Tim Allen  wrote:

> Greetings, friends!
>
> I've issued a PR that makes two changes to the `startproject` template:
>
>- instead of putting configuration files such
>as `settings.py`, `wsgi.py`, and the
>root `urls.py` in `my_project/my_project`, they are created
>in `my_project/config`
>- start the project with a custom User model app, `users`
>
> Over the years, I've taught or tutored over 100 Djangonauts starting their
> first project. Having to distinguish between two directories with the same
> name is a constant pain point in the teaching process - "cd into my_project
> ... no, the other one!"
>
>
>- The `config` option seemed to be the consensus from this thread in
>the forum: Django New Project Structure/Name - Using Django - Django
>Forum (djangoproject.com)
>
>- Ticket: https://github.com/django/django/pull/15609
>
> It is sometimes better to show rather than tell, so following our own
> documentation and including a custom User model with the initial project
> template reinforces the best practice that we explicitly point out in the
> documentation.
>
>
>- Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) –
>Django (djangoproject.com)
>
>- Avoids ever having this come up again:
>
> https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
>
> Here's a link to the PR: https://github.com/django/django/pull/15609
>
> My apologies for not starting with a discussion first. I'm an infrequent
> contributor to the Django codebase!
>
> Regards,
>
> Tim
>
> --
> 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/33cb49d0-2469-47c0-920e-9501245c5a27n%40googlegroups.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/CAMGFDKSKKs08Z3rts4Xeewh1fxNkbmt8LyqqHfofAUF0xs0oAg%40mail.gmail.com.

Re: Stop QuerySet repr from executing queries

['Kevin Weaver' via Django developers (Contributions to Django itself)]

I know this thread is more than a year old, but I was just bitten by this 
as well. We use the Elastic APM Python agent 
 which, like Sentry, calls 
`repr()` on local variables that it sends as part of stack traces. We use 
Django 
REST Framework  and had a 
serializer that looked something like this (fake) example:

```
class AccountSerializer(ModelSerializer):
  owner = PrimaryKeyRelatedField(queryset=User.objects.all())
  days_since_joined = serializers.SerializerMethodField()

  def get_days_since_joined(self, obj):
try:
  ...
except Exception:
  logger.exception(...)
```

What happened was:

   1. We have several places in the application that return a paginated 
   list of, say, 50 accounts, using this serializer.
   2. Someone introduced the log line to catch exceptions when calculating 
   `days_since_joined`, which is called for each of the 50 accounts returned 
   on the page. Due to a bug, the exception was almost always raised.
   3. Each time the exception is raised, the Elastic APM Python agent 
   generates a stack trace and calls `repr()` on local variables in each stack 
   frame. One of those variables in the `get_days_since_joined` frame is the 
   `AccountSerializer` object `self`, which includes the `owner` property. 
   Calling `repr()` on the `owner` property evaluates the `User.objects.all()` 
   QuerySet, which fetches the first 21 User objects from the database.
   4. We now had `SELECT ... FROM user LIMIT 21` being called in a loop 50 
   times each time someone tries to load a page of accounts, suddenly 
   consuming significantly more database CPU and slowing down the application 
   considerably until queries start timing out.

To prevent this from happening again, we ended up applying something very 
similar to the suggestions above as a monkey patch:

```
orig = QuerySet.__repr__

def __repr__(self):
  if settings.DEBUG or self._result_cache:
return orig(self)

  return f"<{self.__class__.__name__} [not evaluated]>"

QuerySet.__repr__ = __repr__
```

If folks are willing to reconsider their positions on this issue, I am more 
than willing to do what is necessary to contribute this change upstream, so 
that others are not impacted by this in the future.

Thank you,

Kevin

On Tuesday, March 23, 2021 at 9:02:39 AM UTC-4 Adam Johnson wrote:

> Would James' suggestion of reusing the result cache in __repr__ have 
> solved your issue? I would like to see that first.
>
> I'm not against the DEBUG-only fetching but there hasn't been any 
> suggestion what to show instead that could be of use.
>
> One can also mitigate against bad queries particularly well by setting a 
> statement timeout at the database level (at least MySQL and PostgreSQL 
> support this), which most users will generally want at a scale where repr() 
> becomes a problem.
>
> On Tue, 23 Mar 2021 at 12:40, Joachim Jablon  wrote:
>
>> Just been bitten by that same bug (combination of Sentry, using a 
>> Queryset.as_manager() that creates an unfiltered queryset as a local 
>> variable in the stack, a create signal that errored provoking a stacktrace 
>> that contained the queryset, a table that is always filtered by a field, 
>> and sorted by another field and an index that behaves poorly without the 
>> aformentionned filter).
>>
>> So would a contribution that would avoid evaluating the uncached queryset 
>> on repr when DEBUG is False likely to be accepted ? If so, I'm ready to get 
>> my hands dirty :)
>>
>> Cheers !
>>
>> Le dimanche 7 mars 2021 à 00:54:56 UTC+1, mic...@turbosys.com.br a 
>> écrit :
>>
>>> I agree with Matt on that. Avoiding executing the queries on production 
>>> would be helpful!
>>>
>>> Let me share my case. I use django-rest-framework in a specific project 
>>> and DRF has a feature: a serializer has a fancier string representation 
>>> when printed. I was using a serializer with a queryset in a view that had 
>>> an exception further, which caused the serializer to be logged and thus, 
>>> the queryset to be executed.
>>>
>>> There are more details in this discussion: 
>>> https://github.com/encode/django-rest-framework/discussions/7782
>>>
>>> The short story is: I was logging this serializer passively and it was 
>>> causing the execution of a query to a whole table with millions of records, 
>>> without any sorting optimization, creating hard to debug performance 
>>> problems.
>>>
>>> I understand it is an unusual situation, but repeating Matt's words: 
>>> Django should be reliable in production for any combination of those 
>>> conditions. 
>>>
>>> Thanks!
>>>
>>> On Sunday, October 20, 2019 at 4:47:25 PM UTC-3 Matt wrote:
>>>
 Perhaps we ought to just keep the current behavior when DEBUG is True 
 (it seems so obvious now, I can't believe it wasn't the first thing I 
 suggested)? Django does lots of helpful things in DEBUG mode at the 
 expense 
 of 

Re: Improvements to the startproject template

[ome chukwuemeka]

I think this is a good suggestion!

On Thu, Apr 21, 2022, 7:08 PM Albert  wrote:

> It is possible to do in current version of Django with two lines of code:
>
> mkdir my_project
>
> django-admin startproject config my_project
>
> I have been working for many companies that use Django and I have seen
> that each ot them has their own structure of project.
>
> And usually project is created once per couple of months, so I don't see
> advantages of changing project structure.
>
> Regards,
>
> Albert
>
> Temat: Re: Improvements to the startproject template
>
> As there are different preferences and some see the change as worse than
> the default and there is already a way to change the template for
> startproject, wouldn't it be easier to provide different templates and list
> them in the documentation, so that they can be used with the --template
> argument? With a short section about each template and the pros and the
> cons, and for what kind of project one is better suited.
>
> Maybe the three top templates could be shipped directly with django, so
> that users could choose one with --template=simple, --template=nested or
> --template=config or something in that direction.
> On Thursday, April 21, 2022 at 11:16:23 AM UTC+2 ator...@redhat.com wrote:
>
>> I personally dislike Adam's suggestion and feel like it makes it worse
>> than the current default, but to each their own.
>>
>> I do prefer the proposed solution of the config directory, I am working
>> on two django projects in parallel and one follows the proposed config
>> scheme and the other doesn't (uses the default) and I find the proposed
>> config scheme more natural to use and navigate, so that's a +1 from me too
>>
>> On Thursday, April 21, 2022 at 5:10:06 AM UTC+2 pem...@gmail.com wrote:
>>
>>> For what it's worth, this is the (general) layout I've used for the past
>>> 8+ years of my professional Django development.
>>>
>>> Arthur
>>>
>>> On Wed, 20 Apr 2022 at 15:22, Olivier Dalang 
>>> wrote:
>>>
 +1 for Adam's suggestion, I use it as well and like it very much.

 > root folder
 - manage.py
 - ...
 > myproject
 - __init__.py
 - settings.py
 - urls.py
 - ...
 > myapp
 - __init__.py
 - models.py
 - ...

 Pros:
 - everything is well namespaced under myproject (`myproject.settings`,
 quite straightforward)
 - makes it clear that `settings.py`, `urls.py`, etc. concern the
 project as a whole, and not just an app.
 - also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it
 clear that myapp is part of this project)
 - it leaves the root level for stuff like .gitignore, db.sqlite, etc,
 so the actual source stays clean from such files.
 - having a parent package allows (does not require) relative imports
 across modules of the same project, which more clearly conveys that such
 apps are tightly coupled
 - with manage.py still in the root folder, you don't need to cd into
 any folder to start working

 I use it all the time.

 Cheers,

 Olivier




 Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :

> I prefer Adam's suggestion in the forum post as it lets you namespace
> everything under your project name nicely and avoids package name
> collisions, although it doesn't solve the problem of having two 
> directories
> with the same name by default.
>
> That said, either would be an improvement on what we have so I'm in
> favour of either approach over doing nothing.
>
> Cheers,
> Tom
>
> On Wed, 20 Apr 2022 at 16:49, John M 
> wrote:
>
>> I do exactly this for every new Django project, so it's +1 from me as
>> well.
>>
>> John
>> On 20/04/2022 12:01, da...@springbourne-tech.com wrote:
>>
>> +1 for me - this would be really useful.
>>
>> On Monday, April 18, 2022 at 9:02:02 PM UTC+1 pyt...@ian.feete.org
>> wrote:
>>
>>> Hi Tim,
>>>
>>> This feels like a good idea to me.
>>>
>>> Regards,
>>> Ian
>>>
>>> On Mon, 18 Apr 2022 at 18:17, Tim Allen 
>>> wrote:
>>>
 Greetings, friends!

 I've issued a PR that makes two changes to the
 `startproject` template:

- instead of putting configuration files such
as `settings.py`, `wsgi.py`, and the
root `urls.py` in `my_project/my_project`, they are created
in `my_project/config`
- start the project with a custom User model app, `users`

 Over the years, I've taught or tutored over 100 Djangonauts
 starting their first project. Having to distinguish between two 
 directories
 with the same name is a constant pain point in the teaching process - 
 "cd
 into 

Re: Improvements to the startproject template

[Hazho Human]

Great one, my all support for this
On Tuesday, 19 April 2022 at 04:02:02 UTC+8 pyt...@ian.feete.org wrote:

> Hi Tim,
>
> This feels like a good idea to me.
>
> Regards,
> Ian
>
> On Mon, 18 Apr 2022 at 18:17, Tim Allen  wrote:
>
>> Greetings, friends!
>>
>> I've issued a PR that makes two changes to the `startproject` template:
>>
>>- instead of putting configuration files such 
>>as `settings.py`, `wsgi.py`, and the 
>>root `urls.py` in `my_project/my_project`, they are created 
>>in `my_project/config`
>>- start the project with a custom User model app, `users`
>>
>> Over the years, I've taught or tutored over 100 Djangonauts starting 
>> their first project. Having to distinguish between two directories with the 
>> same name is a constant pain point in the teaching process - "cd into 
>> my_project ... no, the other one!"
>>
>>
>>- The `config` option seemed to be the consensus from this thread in 
>>the forum: Django New Project Structure/Name - Using Django - Django 
>>Forum (djangoproject.com) 
>>
>>- Ticket: https://github.com/django/django/pull/15609
>>
>> It is sometimes better to show rather than tell, so following our own 
>> documentation and including a custom User model with the initial project 
>> template reinforces the best practice that we explicitly point out in the 
>> documentation.
>>
>>
>>- Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) – 
>>Django (djangoproject.com) 
>>
>>- Avoids ever having this come up again: 
>>
>> https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
>>
>> Here's a link to the PR: https://github.com/django/django/pull/15609
>>
>> My apologies for not starting with a discussion first. I'm an infrequent 
>> contributor to the Django codebase!
>>
>> Regards,
>>
>> Tim
>>
>> -- 
>> 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/33cb49d0-2469-47c0-920e-9501245c5a27n%40googlegroups.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/997e063f-7de4-4dd6-ac5e-cfda209ab776n%40googlegroups.com.

For discussion: JSON-aware views for error responses

[Ville Säävuori]

Hello Django devs!

I'm a long time Django user and nowadays work with sites where Django is 
mostly or only an API for the front end. I'm assuming this is not an exotic 
use case in 2022.

One pain point I continue to come across over and over again is that Django 
by default only speaks text/html even if the request has application/json 
accept headers. This often results in situatios where the unassuming JS app 
burps a HUGE html response as a string to the user when something goes 
wrong. And yes, it's obviously not Djangos fault if the frontend developer 
is sloppy but I believe there's lots of things we could improve here.

Some spesific things we could improve:
- At least for 400, 500, and CSRF errors, send JSON (or empty response) 
back instead of HTML if the request is xhr or has JSON headers
- Make it easy to override the JSON like we can do with HTML
- Add good documentation to explain how this works and how it can be 
customized

I'm interested in hearing comments about this, and opinions from the core 
devs if this would be something that could be built into Django. I haven't 
been active here for a looong time but this is a bit of a pet peeve of mine 
and I would be more than happy to implement this also.

And to be clear, I understand we already have middleware APIs and various 
settings to handle this but my point is that I think handling this in 
Django core (even as an optional setting or middleware) would be most 
useful and right way to do this for the community.

Sorry for the long post.

Cheers,

- VS

-- 
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/68ced6ec-342f-42f6-ba0b-1a51360fa119n%40googlegroups.com.

Re: Improvements to the startproject template

[Albert]

It is possible to do in current version of Django with two lines of code:mkdir 
my_projectdjango-admin startproject config my_projectI have been working for 
many companies that use Django and I have seen that each ot them has their own 
structure of project. And usually project is created once per couple of months, 
so I don't see advantages of changing project structure.Regards,AlbertTemat: 
Re: Improvements to the startproject template
As there are different preferences and some see the change as
  worse than the default and there is already a way to change the
  template for startproject, wouldn't it be easier to provide
  different templates and list them in the documentation, so that
  they can be used with the --template argument? With a short
  section about each template and the pros and the cons, and for
  what kind of project one is better suited.

Maybe the three top templates could be shipped directly with
  django, so that users could choose one with --template=simple,
  --template=nested or --template=config or something in that
  direction.On Thursday, April 21, 2022 at 11:16:23 AM UTC+2 
ator...@redhat.com wrote:I personally dislike Adam's suggestion and feel like 
it makes it worse than the current default, but to each their own.I do prefer 
the proposed solution of the config directory, I am working on two django 
projects in parallel and one follows the proposed config scheme and the other 
doesn't (uses the default) and I find the proposed config scheme more natural 
to use and navigate, so that's a +1 from me tooOn Thursday, April 21, 2022 at 
5:10:06 AM UTC+2 pem...@gmail.com wrote:For what it's worth, this is the 
(general) layout I've used for the past 8+ years of my professional Django 
development.ArthurOn Wed, 20 Apr 2022 at 15:22, Olivier Dalang 
olivier...@gmail.com wrote:+1 for Adam's suggestion, I use it as well 
and like it very much. root folder  - manage.py  - 
...   myproject- __init__.py 
   - settings.py- urls.py 
   - ... myapp  
- __init__.py 
 - models.py  - ...Pros:- 
everything is well namespaced under myproject (`myproject.settings`, quite 
straightforward)- makes it clear that `settings.py`, `urls.py`, etc. concern 
the project as a whole, and not just an app.- also nice in 
settings.INSTALLED_APPS (`myproject.myapp` makes it clear that myapp is part of 
this project)- it leaves the root level for stuff like .gitignore, db.sqlite, 
etc, so the actual source stays clean from such files.- having a parent package 
allows (does not require) relative imports acrossmodules of the same 
project, which more clearly conveys that such apps are tightly coupled- with 
manage.py still in the root folder, you don't need to cd into any folder to 
start workingI use it all the time.Cheers,OlivierLemer. 20 avr. 2022 
à18:50, Tom Carrick t...@carrick.eu a écrit:I prefer Adam's 
suggestion in the forum post as it lets you namespace everything under your 
project name nicely and avoids package name collisions, although it doesn't 
solve the problem of having two directories with the same name by default.That 
said, either would be an improvement on what we have so I'm in favour of either 
approach over doing nothing.Cheers,TomOn Wed, 20 Apr 2022 at 16:49, John M 
john-...@martinhome.org.uk wrote:
  

  
  
I do exactly this for every new Django project, so it's +1 from
  me as well.
John

On 20/04/2022 12:01,
  da...@springbourne-tech.com wrote:


  
  +1 for me - this would be really useful.
  
  
On Monday, April 18, 2022 at
  9:02:02 PM UTC+1 pyt...@ian.feete.org wrote:


  
Hi Tim,


This feels like a good idea to me.


Regards,
Ian

  
  
  
On Mon, 18 Apr 2022 at
  18:17, Tim Allen fli...@peregrinesalon.com
  wrote:

  
  
Greetings, friends!
  
  
  I've issued a PR that makes two changes to the
`startproject`template:
  

  instead of putting configuration files such
as`settings.py`,`wsgi.py`, and the
root`urls.py`in`my_project/my_project`, 
they are
created in`my_project/config`
  start the project with a custom User model
app,`users`

Over the years, I've taught or tutored
  over 100 Djangonauts starting their first project.
  Having to distinguish between two directories with the
  same name is a constant pain point in the teaching
  process - "cd into my_project ... no, the other one!"

  The 

Re: Improvements to the startproject template

[Sandro Covo]

As there are different preferences and some see the change as worse than 
the default and there is already a way to change the template for 
startproject, wouldn't it be easier to provide different templates and list 
them in the documentation, so that they can be used with the --template 
argument? With a short section about each template and the pros and the 
cons, and for what kind of project one is better suited.

Maybe the three top templates could be shipped directly with django, so 
that users could choose one with --template=simple, --template=nested or 
--template=config or something in that direction.
On Thursday, April 21, 2022 at 11:16:23 AM UTC+2 ator...@redhat.com wrote:

> I personally dislike Adam's suggestion and feel like it makes it worse 
> than the current default, but to each their own.
>
> I do prefer the proposed solution of the config directory, I am working on 
> two django projects in parallel and one follows the proposed config scheme 
> and the other doesn't (uses the default) and I find the proposed config 
> scheme more natural to use and navigate, so that's a +1 from me too
>
> On Thursday, April 21, 2022 at 5:10:06 AM UTC+2 pem...@gmail.com wrote:
>
>> For what it's worth, this is the (general) layout I've used for the past 
>> 8+ years of my professional Django development.
>>
>> Arthur
>>
>> On Wed, 20 Apr 2022 at 15:22, Olivier Dalang  
>> wrote:
>>
>>> +1 for Adam's suggestion, I use it as well and like it very much.
>>>
>>> > root folder
>>> - manage.py
>>> - ...
>>> > myproject
>>> - __init__.py
>>> - settings.py
>>> - urls.py
>>> - ...
>>> > myapp
>>> - __init__.py
>>> - models.py
>>> - ...
>>>
>>> Pros:
>>> - everything is well namespaced under myproject (`myproject.settings`, 
>>> quite straightforward)
>>> - makes it clear that `settings.py`, `urls.py`, etc. concern the project 
>>> as a whole, and not just an app.
>>> - also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it clear 
>>> that myapp is part of this project)
>>> - it leaves the root level for stuff like .gitignore, db.sqlite, etc, so 
>>> the actual source stays clean from such files.
>>> - having a parent package allows (does not require) relative imports 
>>> across modules of the same project, which more clearly conveys that such 
>>> apps are tightly coupled
>>> - with manage.py still in the root folder, you don't need to cd into any 
>>> folder to start working
>>>
>>> I use it all the time.
>>>
>>> Cheers,
>>>
>>> Olivier
>>>
>>>
>>>
>>>
>>> Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :
>>>
 I prefer Adam's suggestion in the forum post as it lets you namespace 
 everything under your project name nicely and avoids package name 
 collisions, although it doesn't solve the problem of having two 
 directories 
 with the same name by default.

 That said, either would be an improvement on what we have so I'm in 
 favour of either approach over doing nothing.

 Cheers,
 Tom

 On Wed, 20 Apr 2022 at 16:49, John M  
 wrote:

> I do exactly this for every new Django project, so it's +1 from me as 
> well.
>
> John
> On 20/04/2022 12:01, da...@springbourne-tech.com wrote:
>
> +1 for me - this would be really useful.
>
> On Monday, April 18, 2022 at 9:02:02 PM UTC+1 pyt...@ian.feete.org 
> wrote:
>
>> Hi Tim,
>>
>> This feels like a good idea to me.
>>
>> Regards,
>> Ian
>>
>> On Mon, 18 Apr 2022 at 18:17, Tim Allen  
>> wrote:
>>
>>> Greetings, friends! 
>>>
>>> I've issued a PR that makes two changes to the 
>>> `startproject` template:
>>>
>>>- instead of putting configuration files such 
>>>as `settings.py`, `wsgi.py`, and the 
>>>root `urls.py` in `my_project/my_project`, they are created 
>>>in `my_project/config` 
>>>- start the project with a custom User model app, `users` 
>>>
>>> Over the years, I've taught or tutored over 100 Djangonauts starting 
>>> their first project. Having to distinguish between two directories with 
>>> the 
>>> same name is a constant pain point in the teaching process - "cd into 
>>> my_project ... no, the other one!"
>>>
>>>- The `config` option seemed to be the consensus from this 
>>>thread in the forum: Django New Project Structure/Name - Using 
>>>Django - Django Forum (djangoproject.com) 
>>>
>>> 
>>>  
>>>- Ticket: https://github.com/django/django/pull/15609 
>>>
>>> It is sometimes better to show rather than tell, so following our 
>>> own documentation and including a custom User model with the initial 
>>> project template reinforces the best practice that we explicitly point 
>>> out 

Re: Improvements to the startproject template

[Adrian Torres Justo]

I personally dislike Adam's suggestion and feel like it makes it worse than 
the current default, but to each their own.

I do prefer the proposed solution of the config directory, I am working on 
two django projects in parallel and one follows the proposed config scheme 
and the other doesn't (uses the default) and I find the proposed config 
scheme more natural to use and navigate, so that's a +1 from me too

On Thursday, April 21, 2022 at 5:10:06 AM UTC+2 pem...@gmail.com wrote:

> For what it's worth, this is the (general) layout I've used for the past 
> 8+ years of my professional Django development.
>
> Arthur
>
> On Wed, 20 Apr 2022 at 15:22, Olivier Dalang  wrote:
>
>> +1 for Adam's suggestion, I use it as well and like it very much.
>>
>> > root folder
>> - manage.py
>> - ...
>> > myproject
>> - __init__.py
>> - settings.py
>> - urls.py
>> - ...
>> > myapp
>> - __init__.py
>> - models.py
>> - ...
>>
>> Pros:
>> - everything is well namespaced under myproject (`myproject.settings`, 
>> quite straightforward)
>> - makes it clear that `settings.py`, `urls.py`, etc. concern the project 
>> as a whole, and not just an app.
>> - also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it clear 
>> that myapp is part of this project)
>> - it leaves the root level for stuff like .gitignore, db.sqlite, etc, so 
>> the actual source stays clean from such files.
>> - having a parent package allows (does not require) relative imports 
>> across modules of the same project, which more clearly conveys that such 
>> apps are tightly coupled
>> - with manage.py still in the root folder, you don't need to cd into any 
>> folder to start working
>>
>> I use it all the time.
>>
>> Cheers,
>>
>> Olivier
>>
>>
>>
>>
>> Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :
>>
>>> I prefer Adam's suggestion in the forum post as it lets you namespace 
>>> everything under your project name nicely and avoids package name 
>>> collisions, although it doesn't solve the problem of having two directories 
>>> with the same name by default.
>>>
>>> That said, either would be an improvement on what we have so I'm in 
>>> favour of either approach over doing nothing.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Wed, 20 Apr 2022 at 16:49, John M  wrote:
>>>
 I do exactly this for every new Django project, so it's +1 from me as 
 well.

 John
 On 20/04/2022 12:01, da...@springbourne-tech.com wrote:

 +1 for me - this would be really useful.

 On Monday, April 18, 2022 at 9:02:02 PM UTC+1 pyt...@ian.feete.org 
 wrote:

> Hi Tim,
>
> This feels like a good idea to me.
>
> Regards,
> Ian
>
> On Mon, 18 Apr 2022 at 18:17, Tim Allen  
> wrote:
>
>> Greetings, friends! 
>>
>> I've issued a PR that makes two changes to the 
>> `startproject` template:
>>
>>- instead of putting configuration files such 
>>as `settings.py`, `wsgi.py`, and the 
>>root `urls.py` in `my_project/my_project`, they are created 
>>in `my_project/config` 
>>- start the project with a custom User model app, `users` 
>>
>> Over the years, I've taught or tutored over 100 Djangonauts starting 
>> their first project. Having to distinguish between two directories with 
>> the 
>> same name is a constant pain point in the teaching process - "cd into 
>> my_project ... no, the other one!"
>>
>>- The `config` option seemed to be the consensus from this thread 
>>in the forum: Django New Project Structure/Name - Using Django - 
>>Django Forum (djangoproject.com) 
>>
>> 
>>  
>>- Ticket: https://github.com/django/django/pull/15609 
>>
>> It is sometimes better to show rather than tell, so following our own 
>> documentation and including a custom User model with the initial project 
>> template reinforces the best practice that we explicitly point out in 
>> the 
>> documentation.
>>
>>- Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) 
>>– Django (djangoproject.com) 
>> 
>>- Avoids ever having this come up again: 
>>
>> https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
>>  
>>
>> Here's a link to the PR: https://github.com/django/django/pull/15609
>>
>> My apologies for not starting with a discussion first. I'm an 
>> infrequent contributor to the Django codebase!
>>
>> Regards,
>>
>> Tim
>>
> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group