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

Exactly, I believe a best practices section should be added to the already robust Django documentation. Something akin to the Two Scoops of Django book. That would be better than focusing a pattern on everyone. On Fri, 11 Oct 2019, 13:21 Carlton Gibson, wrote: > I can see a How-To explaining dif

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

This feature should be filled under a "nice to have" and not a "must have". On Fri, 11 Oct 2019, 12:45 Mariusz Felisiak, wrote: > Hi, > > I don't agree that Django should force pattern with multiple settings > files (*base, development, staging, and production*) there is many ways > to keep

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

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: Django Async DEP

Django 3.0? On Sun, Jul 21, 2019 at 9:02 PM Andrew Godwin wrote: > I'll ask permission and then summarise the points raised back out here! > > Andrew > > On Sun, Jul 21, 2019 at 1:01 PM Jacob Kaplan-Moss > wrote: > >> Congratulations, and great news! >> >> I hope the TB will consider sharing de

Re: Python 3.8 and Django 2.2.3 Issues

. Hope my apology is accepted. Thank you all very much for your help. Kind regards On Monday, July 15, 2019 at 1:25:24 PM UTC+1, Curtis Maloney wrote: > > > > On Mon, 15 Jul 2019, at 22:13, Ehigie Aito wrote: > > Like I said, I didn't say the problem was from Django. I said

Re: Python 3.8 and Django 2.2.3 Issues

n, 15 Jul 2019, at 22:13, Ehigie Aito wrote: > > Like I said, I didn't say the problem was from Django. I said it's from > Python 3.8 because creating a project with Python 3.7 doesn't produce this > traceback. > > > I think it's quite clear there is an inc

Re: Python 3.8 and Django 2.2.3 Issues

Like I said, I didn't say the problem was from Django. I said it's from Python 3.8 because creating a project with Python 3.7 doesn't produce this traceback. On Mon, 15 Jul 2019, 13:07 Curtis Maloney, wrote: > I think you're making an assumption about the cause of the problem, > without evidence

Re: Python 3.8 and Django 2.2.3 Issues

, Ehigie Aito wrote: > > This is the contents of the file generated when I use Python 3.7.3 and > Django 2.2.3 > > from django.utils.version import get_version > > VERSION = (2, 2, 3, 'final', 0) > > __version__ = get_version(VERSION) > > > def setup(s

Re: Python 3.8 and Django 2.2.3 Issues

, Ehigie Aito wrote: > > This is the contents of the file generated when I use Python 3.7.3 and > Django 2.2.3 > > from django.utils.version import get_version > > VERSION = (2, 2, 3, 'final', 0) > > __version__ = get_version(VERSION) > > > def setup(s

Re: Python 3.8 and Django 2.2.3 Issues

PT_NAME is None else settings.FORCE_SCRIPT_NAME ) apps.populate(settings.INSTALLED_APPS) Notice anything? Django 2.2.3 and Python 3.8.0 b1 fails On Monday, July 15, 2019 at 12:44:04 PM UTC+1, James Bennett wrote: > > On Mon, Jul 15, 2019 at 4:41 AM Ehigie Aito > wrote: > >>

Re: Python 3.8 and Django 2.2.3 Issues

nday, July 15, 2019 at 12:42:16 PM UTC+1, Curtis Maloney wrote: > > On Mon, 15 Jul 2019, at 21:36, Ehigie Aito wrote: > > Like I said, in older versions of Django, that variable used to be named > MIDDLEWARE_CLASSES, if I create a Django project with Python 3.7 and Django > 2.2.3,

Re: Python 3.8 and Django 2.2.3 Issues

Not at all, I create all new Django projects from scratch and with pipenv. This only happens with Python 3.8.0 b1 On Mon, Jul 15, 2019 at 12:39 PM James Bennett wrote: > On Mon, Jul 15, 2019 at 4:36 AM Ehigie Aito wrote: > >> Like I said, in older versions of Django, that variabl

Re: Python 3.8 and Django 2.2.3 Issues

Like I said, in older versions of Django, that variable used to be named MIDDLEWARE_CLASSES, if I create a Django project with Python 3.7 and Django 2.2.3, its MIDDLEWARE but Python 3.8 and Django 2.2.3 its named MIDDLEWARE_CLASSES which on running python manage.py runserver fails. Here is the trac

Python 3.8 and Django 2.2.3 Issues

Creating a project with Python 3.8 and Django 2.2.3, the MIDDLEWARE variable in the (link: http://settings.py) settings.py file is changed to MIDDLEWARE_CLASSES which makes running this command: '(link: http://manage.py) manage.py