Re: Removing old branches from the Django Git repository.

[Carlton Gibson]

Tom’s Tag idea seems to hit the balance.

I’d like to clean them out. I use git branch all day and they’re just noise
there.

Tags would keep the references we’d need to check them out, without the
additional work of creating a separate repo, or learning new/arcane git
features, which don’t merit the effort on any given day.

On Fri, 11 Oct 2019 at 02:28, Tim Graham  wrote:

> Same proposal from 2016:
> https://groups.google.com/d/topic/django-developers/sf2adeIAkQA/discussion
>
> On Thursday, October 10, 2019 at 4:09:24 PM UTC-4, Tom Forbes wrote:
>>
>> I second this, there are a few other branches in that list (successful or
>> not) that have historic value to Django. Is there a pressing need to delete
>> them, other than spring cleaning?
>>
>> I guess maybe it’s sentimental value, and nobody would ever check them
>> out, but still...
>>
>> Tom
>>
>> On 10 Oct 2019, at 20:15, Adam Johnson  wrote:
>>
>> Can we leave magic-removal as a tag since it’s such a pivotal point in
>> djangos history? xD
>>
>> On Thu, 10 Oct 2019 at 19:09, Mariusz Felisiak 
>> wrote:
>>
>> Hi y'all,
>>>
>>> We're going to remove some old branches from the Django Git
>>> repository on 1st November 2019:
>>>
>>>- *9* old branches related with Google SOC projects:
>>>- soc2009/admin-ui
>>>   - soc2009/http-wsgi-improvements
>>>   - soc2009/i18n-improvements
>>>   - soc2009/model-validation
>>>   - soc2009/multidb
>>>   - soc2009/test-improvements
>>>   - soc2010/app-loading
>>>   - soc2010/query-refactor
>>>   - soc2010/test-refactor
>>>- *17* *attic* branches:
>>>   - attic/boulder-oracle-sprint
>>>   - attic/full-history
>>>   - attic/generic-auth
>>>   - attic/gis
>>>   - attic/i18n
>>>   - attic/magic-removal
>>>   - attic/multi-auth
>>>   - attic/multiple-db-support
>>>   - attic/new-admin
>>>   - attic/newforms-admin
>>>   - attic/per-object-permissions
>>>   - attic/queryset-refactor
>>>   - attic/schema-evolution
>>>   - attic/schema-evolution-ng
>>>   - attic/search-api
>>>   - attic/sqlalchemy
>>>   - attic/unicode
>>>
>>> Best,
>>> Mariusz
>>>
>>> --
>>> 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-d...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/9837cb41-66bc-40f2-8296-75f0ad173ee3%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> Adam
>>
>> --
>> 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-d...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM2kqTztbjzBg%2BOtTCO1M-5TxpaguH60BNv3m5TUe2T-dw%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/c044ea54-e537-4141-ad1c-a3b034149f5d%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/CAJwKpyQsJEDMCxooHPiy3ZOS4sDr3OG5FANuoDGOGz7Z0TKskg%40mail.gmail.com.

Re: Removing old branches from the Django Git repository.

[Tim Graham]

Same proposal from 
2016: https://groups.google.com/d/topic/django-developers/sf2adeIAkQA/discussion

On Thursday, October 10, 2019 at 4:09:24 PM UTC-4, Tom Forbes wrote:
>
> I second this, there are a few other branches in that list (successful or 
> not) that have historic value to Django. Is there a pressing need to delete 
> them, other than spring cleaning?
>
> I guess maybe it’s sentimental value, and nobody would ever check them 
> out, but still...
>
> Tom
>
> On 10 Oct 2019, at 20:15, Adam Johnson > 
> wrote:
>
> 
> Can we leave magic-removal as a tag since it’s such a pivotal point in 
> djangos history? xD
>
> On Thu, 10 Oct 2019 at 19:09, Mariusz Felisiak  > wrote:
>
>> Hi y'all,
>>
>> We're going to remove some old branches from the Django Git 
>> repository on 1st November 2019:
>>
>>- *9* old branches related with Google SOC projects:
>>- soc2009/admin-ui
>>   - soc2009/http-wsgi-improvements
>>   - soc2009/i18n-improvements
>>   - soc2009/model-validation
>>   - soc2009/multidb
>>   - soc2009/test-improvements
>>   - soc2010/app-loading
>>   - soc2010/query-refactor
>>   - soc2010/test-refactor
>>- *17* *attic* branches:
>>   - attic/boulder-oracle-sprint
>>   - attic/full-history
>>   - attic/generic-auth
>>   - attic/gis
>>   - attic/i18n
>>   - attic/magic-removal
>>   - attic/multi-auth
>>   - attic/multiple-db-support
>>   - attic/new-admin
>>   - attic/newforms-admin
>>   - attic/per-object-permissions
>>   - attic/queryset-refactor
>>   - attic/schema-evolution
>>   - attic/schema-evolution-ng
>>   - attic/search-api
>>   - attic/sqlalchemy
>>   - attic/unicode
>>
>> Best,
>> Mariusz
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/9837cb41-66bc-40f2-8296-75f0ad173ee3%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
> Adam
>
> -- 
> 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-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2kqTztbjzBg%2BOtTCO1M-5TxpaguH60BNv3m5TUe2T-dw%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/c044ea54-e537-4141-ad1c-a3b034149f5d%40googlegroups.com.

Re: Form customization

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

Try tri.forms maybe

The main problem IMHO is that rendering is stuck in a template system, rather 
than components that could leverage the decorator pattern as it's known to be 
better for UI programing (cf. GoF, React & friends success)

‐‐‐ Original Message ‐‐‐
Le dimanche 6 octobre 2019 01:11, Alex Scott  a écrit :

> Hi all,
>
> Are there any current plans or developments to allow better customization of 
> forms?  I've browsed several old Stack Overflow, django-users and Django 
> ticket requests and it seems common enough to want to say, add a class to 
> every form field or field label, or change the label suffix from ":" to "".
>
> The current "solutions" seem hacky and non-DRY, usually requiring custom code 
> for every form used in a site.
>
> Would it be a terrible idea to allow these to be set in settings or in a base 
> form that gets inherited by everything else?
>
> Thanks,
> Alex
>
> --
> 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/CAMiVppbh%2BOAWa6z0k0m2uQj0ZrguCAzgz3tt3yhWa6_FjMO_ow%40mail.gmail.com](https://groups.google.com/d/msgid/django-developers/CAMiVppbh%2BOAWa6z0k0m2uQj0ZrguCAzgz3tt3yhWa6_FjMO_ow%40mail.gmail.com?utm_medium=email&utm_source=footer).

-- 
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/qBTxFiY0cYK-jSS7a21kO2PZRvcMP1IQ1nwVLpYd5KwThgQPDuGhexO_OzV0MrTtuwd8ZnEpnp6cMnpMb4rSyMzNeHvrb3IUDAUOV7n_bz4%3D%40protonmail.com.

Re: django-admin startproject settings.py has some security holes

[Ehigie Aito]

Hello Bobby,
I think this should be added to a best practises documentation and not
codified in Django. As I feel that would be overkill.

On Thu, 10 Oct 2019, 20:41 Bobby Mozumder,  wrote:

> In particular, they include settings that shouldn’t be stored in a git
> repo such as SECRET_KEY and database passwords. You’ll find these kinds of
> settings in git repos all the time.
>
> Really the default django-admin startproject shouldn’t have a single
> settings.py that people include in their git repos, but instead a python
> settings module, with a base.py, development.py, staging.py, and
> production.py. An __init__.py reads base.py and one of
> development/staging/production based on ENV variables (defaulting to
> development if no ENV variable).
>
> Additionally, startproject should add a .gitignore in the root directory
> to not include development/staging/production settings files.
>
> I get that this might not be absolutely necessary but I think these are
> the kinds of defaults that make practical real-world use more secure, as
> well as standardizing workflow for more advanced production usage.
>
> Is this something agreeable? I can put together a solution if people like
> this.
>
> -bobby
>
>
> --
> 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/320B70FD-BDC1-445D-B72B-0CD0BA736B88%40gmail.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/CA%2BB1BD6kxbSR_fOwAWxY%3DtjRA30YPcYVt87%2BHguOKyZBOnHnuQ%40mail.gmail.com.

Re: Form customization

[Jacob Rief]

With Django-1.10 we got the ability to override form fields with our own 
templates, however the form structure is still hard-coded.
Examples are BaseForm.as_table() 
,
 
BaseForm.as_ul() 

 
and BaseForm.as_p() 


For instance, the popular Bootstrap framework requires a  wrapped around each field, so I created a mixin class 
which I add to my Django Forms.
There I added a method named as_div() which renders all my fields in a 
Bootstrap-ish way. This of course is not very intuitive.

My question here is, couldn't we make the arguments normal_row, error_row, 
row_ender and help_text_html, which are passed to method self._html_output, 
more configurable?
Those arguments could maybe be replaced by some special templatetags and 
then consumed by a template responsible to render the form structure in a 
similar way as the as_...() methods mentioned before.

-- 
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/6eb291eb-91f9-4af0-9cd2-ae3fddc5ae4d%40googlegroups.com.

Re: Removing old branches from the Django Git repository.

[Tom Forbes]

I second this, there are a few other branches in that list (successful or not) 
that have historic value to Django. Is there a pressing need to delete them, 
other than spring cleaning?

I guess maybe it’s sentimental value, and nobody would ever check them out, but 
still...

Tom

> On 10 Oct 2019, at 20:15, Adam Johnson  wrote:
> 
> 
> Can we leave magic-removal as a tag since it’s such a pivotal point in 
> djangos history? xD
> 
>> On Thu, 10 Oct 2019 at 19:09, Mariusz Felisiak  
>> wrote:
>> Hi y'all,
>> 
>> We're going to remove some old branches from the Django Git repository 
>> on 1st November 2019:
>> 9 old branches related with Google SOC projects:
>> soc2009/admin-ui
>> soc2009/http-wsgi-improvements
>> soc2009/i18n-improvements
>> soc2009/model-validation
>> soc2009/multidb
>> soc2009/test-improvements
>> soc2010/app-loading
>> soc2010/query-refactor
>> soc2010/test-refactor
>> 17 attic branches:
>> attic/boulder-oracle-sprint
>> attic/full-history
>> attic/generic-auth
>> attic/gis
>> attic/i18n
>> attic/magic-removal
>> attic/multi-auth
>> attic/multiple-db-support
>> attic/new-admin
>> attic/newforms-admin
>> attic/per-object-permissions
>> attic/queryset-refactor
>> attic/schema-evolution
>> attic/schema-evolution-ng
>> attic/search-api
>> attic/sqlalchemy
>> attic/unicode
>> Best,
>> Mariusz
>> 
>> -- 
>> 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/9837cb41-66bc-40f2-8296-75f0ad173ee3%40googlegroups.com.
> -- 
> Adam
> -- 
> 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/CAMyDDM2kqTztbjzBg%2BOtTCO1M-5TxpaguH60BNv3m5TUe2T-dw%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/07142C38-7A56-4F8E-979A-A2574DB40026%40tomforb.es.

django-admin startproject settings.py has some security holes

[Bobby Mozumder]

In particular, they include settings that shouldn’t be stored in a git repo 
such as SECRET_KEY and database passwords. You’ll find these kinds of settings 
in git repos all the time.

Really the default django-admin startproject shouldn’t have a single 
settings.py that people include in their git repos, but instead a python 
settings module, with a base.py, development.py, staging.py, and production.py. 
An __init__.py reads base.py and one of development/staging/production based on 
ENV variables (defaulting to development if no ENV variable).

Additionally, startproject should add a .gitignore in the root directory to not 
include development/staging/production settings files.

I get that this might not be absolutely necessary but I think these are the 
kinds of defaults that make practical real-world use more secure, as well as 
standardizing workflow for more advanced production usage.

Is this something agreeable? I can put together a solution if people like this.

-bobby
   

-- 
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/320B70FD-BDC1-445D-B72B-0CD0BA736B88%40gmail.com.

Re: Stop QuerySet repr from executing queries

[Adam Johnson]

I’m in favour of changing repr to not execute. Luke’s reasoning seems
reasonable.

On Thu, 10 Oct 2019 at 17:15, Ryan Hiebert  wrote:

>
>
> On Thu, Oct 10, 2019 at 10:50 AM Matt  wrote:
>
>>
>> I think we ought to reconsider the behavior of repr on QuerySets. I'm of
>> the opinion that we should scrap it completely. It could be replaced by
>> something that generates the SQL that would be executed (although that may
>> be tricky), or some kind of representation of the query filter.
>>
>
> Just speaking for myself, I think I'm roughly in agreement with the
> general sentiment and reasoning behind your proposal. There's one place
> that I think there's common utility, and which I think is the most likely
> the cause disruption to people, the interactive prompt. The issues that
> you've mentioned are also present on the interactive prompt as well, so the
> change would be optimal there as well. Perhaps it would be possible to ease
> the pain somewhat if there were a setting to do reprs as currently, perhaps
> _only_ on the interactive prompt, to avoid the issues you've pointed out
> with tools like Sentry. I'm not sure what the default setting value should
> be, though I do think new projects should include whatever settings would
> be needed to make this the default behavior for new projects, even if the
> setting default was to maintain backward compatibility, as has been done
> for other settings.
>
> tl;dr: I like the motivation, but I'm not sure how the backward
> compatibility aspects will play out for the community.
>
> --
> 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/CABpHFHS1%3DirRaQVWgiUnmTX%2By%3DB7Vy%2BpGLha-aoYmqTGUSj20g%40mail.gmail.com
> 
> .
>
-- 
Adam

-- 
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/CAMyDDM0XNtKYEVy3kMGz0mFD5JHcOdLzEb5fDj22jpsKAr4vjQ%40mail.gmail.com.

Re: Removing old branches from the Django Git repository.

[Adam Johnson]

Can we leave magic-removal as a tag since it’s such a pivotal point in
djangos history? xD

On Thu, 10 Oct 2019 at 19:09, Mariusz Felisiak 
wrote:

> Hi y'all,
>
> We're going to remove some old branches from the Django Git repository
> on 1st November 2019:
>
>- *9* old branches related with Google SOC projects:
>- soc2009/admin-ui
>   - soc2009/http-wsgi-improvements
>   - soc2009/i18n-improvements
>   - soc2009/model-validation
>   - soc2009/multidb
>   - soc2009/test-improvements
>   - soc2010/app-loading
>   - soc2010/query-refactor
>   - soc2010/test-refactor
>- *17* *attic* branches:
>   - attic/boulder-oracle-sprint
>   - attic/full-history
>   - attic/generic-auth
>   - attic/gis
>   - attic/i18n
>   - attic/magic-removal
>   - attic/multi-auth
>   - attic/multiple-db-support
>   - attic/new-admin
>   - attic/newforms-admin
>   - attic/per-object-permissions
>   - attic/queryset-refactor
>   - attic/schema-evolution
>   - attic/schema-evolution-ng
>   - attic/search-api
>   - attic/sqlalchemy
>   - attic/unicode
>
> Best,
> Mariusz
>
> --
> 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/9837cb41-66bc-40f2-8296-75f0ad173ee3%40googlegroups.com
> 
> .
>
-- 
Adam

-- 
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/CAMyDDM2kqTztbjzBg%2BOtTCO1M-5TxpaguH60BNv3m5TUe2T-dw%40mail.gmail.com.

Removing old branches from the Django Git repository.

[Mariusz Felisiak]

Hi y'all,

We're going to remove some old branches from the Django Git repository 
on 1st November 2019:

   - *9* old branches related with Google SOC projects:
   - soc2009/admin-ui
  - soc2009/http-wsgi-improvements
  - soc2009/i18n-improvements
  - soc2009/model-validation
  - soc2009/multidb
  - soc2009/test-improvements
  - soc2010/app-loading
  - soc2010/query-refactor
  - soc2010/test-refactor
   - *17* *attic* branches:
  - attic/boulder-oracle-sprint
  - attic/full-history
  - attic/generic-auth
  - attic/gis
  - attic/i18n
  - attic/magic-removal
  - attic/multi-auth
  - attic/multiple-db-support
  - attic/new-admin
  - attic/newforms-admin
  - attic/per-object-permissions
  - attic/queryset-refactor
  - attic/schema-evolution
  - attic/schema-evolution-ng
  - attic/search-api
  - attic/sqlalchemy
  - attic/unicode
   
Best,
Mariusz

-- 
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/9837cb41-66bc-40f2-8296-75f0ad173ee3%40googlegroups.com.

Re: Form customization

[Alex Scott]

Yeah it very well might be the case that I'm missing something or that some 
additional documentation is all we need (I'm not new to Django but far from 
an expert and took a long hiatus).

The first example is the label suffix, which seems to be given a hard coded 
default here 
.
  
I think there are many ways to override / deal with this, but if you're 
using a mix of Forms and ModelForms and want to still enjoy much of the 
magic of Django, what's the recommended solution to, say, remove that colon 
in all your forms?  Seems like you can... (1) Just manually write the 
labels yourself in the template (2) Create new base form classes that 
extend Form/ModelForm and remove the colon, and then make sure all your 
forms use those (3) Manually deal with this in form instantiation or via 
get_form() or some other method (4) Maybe more?

As a lay user, this all seems pretty complex to change something so 
seemingly simple and there doesn't seem to be a "recommended" way.

Another example is say, adding a class to every input field because you 
want to style them appropriately.  Solutions to this exist, but they again 
seem far from "plug n play", even when I'm guessing a majority of users 
want to do this (since if you're using Bootstrap, Foundation, Bulma, etc 
it's needed).

I have a few more examples but will stop there.  Let me know what you think.

On Tuesday, October 8, 2019 at 12:53:42 AM UTC-7, Carlton Gibson wrote:
>
> Hi Alex
>
> Can you be more specific please? 
>
> On Sunday, 6 October 2019 01:11:52 UTC+2, Alex Scott wrote:
>>
>> Would it be a terrible idea to allow these to be set in settings or in a 
>> base form that gets inherited by everything else?
>>
>
>  Without seeing exactly the problems you have in mind, it's hard to say... 
> — By using a base form class in your project, overriding templates, and/or 
> default field mappings, I would imagine everything you need is already 
> possible. 
>
> (Quite likely there's room for a deeper How To on advanced form 
> customisation in the docs though.)
>
> Kind Regards,
>
> Carlton
>
>

-- 
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/718e0ea1-5375-4c81-b0d2-5a2b6b742685%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

[Ryan Hiebert]

On Thu, Oct 10, 2019 at 10:50 AM Matt  wrote:

>
> I think we ought to reconsider the behavior of repr on QuerySets. I'm of
> the opinion that we should scrap it completely. It could be replaced by
> something that generates the SQL that would be executed (although that may
> be tricky), or some kind of representation of the query filter.
>

Just speaking for myself, I think I'm roughly in agreement with the general
sentiment and reasoning behind your proposal. There's one place that I
think there's common utility, and which I think is the most likely the
cause disruption to people, the interactive prompt. The issues that you've
mentioned are also present on the interactive prompt as well, so the change
would be optimal there as well. Perhaps it would be possible to ease the
pain somewhat if there were a setting to do reprs as currently, perhaps
_only_ on the interactive prompt, to avoid the issues you've pointed out
with tools like Sentry. I'm not sure what the default setting value should
be, though I do think new projects should include whatever settings would
be needed to make this the default behavior for new projects, even if the
setting default was to maintain backward compatibility, as has been done
for other settings.

tl;dr: I like the motivation, but I'm not sure how the backward
compatibility aspects will play out for the community.

-- 
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/CABpHFHS1%3DirRaQVWgiUnmTX%2By%3DB7Vy%2BpGLha-aoYmqTGUSj20g%40mail.gmail.com.

Stop QuerySet repr from executing queries

[Matt]

repr(some_queryset) will execute the query and display some results from 
the query. This is done because it's (somewhat) helpful for debugging.

https://github.com/django/django/blob/2a6f45e08e8cb8c7e5157915c378b453109424d2/django/db/models/query.py#L248

This has caused at least two people to scratch their heads about odd 
queries being generated, and it crashed my production database yesterday.

See #20393  and #30863 


Luke Plant has said:

... you have a conflict between the goal of being information rich and with 
> *always* being useful for debugging. In general, automatically seeing the 
> results is information rich and is useful in debugging, but sometimes it 
> causes further problems.
>
> I have thought about it, and with this conflict of goals, I think we are 
> going to have to err on the side of the current behaviour. It is possible 
> to work around by not calling repr on QuerySets in your middleware, and 
> there are too many people who will be upset (or have problems with their 
> own debugging facilities) by changing this.
>

One reason people love Django is because of its attention to things like 
debug-ability. I can certainly see the argument here. However, I want to 
press on the desirability of this feature.

The argument that you can work around it by not calling repr is certainly 
true, but in practice, I don't think it's reasonable. Production error 
reporting tools (like Sentry and New Relic) will call repr when reporting 
on exceptions.

I see this behavior as being analogous to a file object printing the first 
21 characters of a file, which it doesn't do (for good reason, I would 
imagine):

>>> f = open("foo.py")
>>> repr(f)
"<_io.TextIOWrapper name='foo.py' mode='r' encoding='UTF-8'>"
>>>

I think we ought to reconsider the behavior of repr on QuerySets. I'm of 
the opinion that we should scrap it completely. It could be replaced by 
something that generates the SQL that would be executed (although that may 
be tricky), or some kind of representation of the query filter. 

Any thoughts?

-- 
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/29051be5-2988-4295-a8d9-1c5ae9555ee1%40googlegroups.com.