Re: Removing old branches from the Django Git repository.

2019-10-10 Thread 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 t

Re: Removing old branches from the Django Git repository.

2019-10-10 Thread 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 the

Re: Form customization

2019-10-10 Thread '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

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

2019-10-10 Thread 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 datab

Re: Form customization

2019-10-10 Thread 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()

Re: Removing old branches from the Django Git repository.

2019-10-10 Thread 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

django-admin startproject settings.py has some security holes

2019-10-10 Thread 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

Re: Stop QuerySet repr from executing queries

2019-10-10 Thread 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 s

Re: Removing old branches from the Django Git repository.

2019-10-10 Thread 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 wi

Removing old branches from the Django Git repository.

2019-10-10 Thread 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

Re: Form customization

2019-10-10 Thread 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

Re: Stop QuerySet repr from executing queries

2019-10-10 Thread 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 ki

Stop QuerySet repr from executing queries

2019-10-10 Thread 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 sc