[sametmax]

Actually, I think settings.py is not a bad idea, but it's half backed.

There should have a schema checking the setting file. There should have a better way to extend settings, and make different settings according to context, such as prod, staging or dev.

There should be a linter avoiding stupid mistakes like missing a coma in a tuple, resulting in string concatenation.

There should be variables giving you basic stuff like current dir, log dir, var dir, etc. We all make them anyway.

And there should be a better to debug the import settings problem.

But all in all, it's quick and easy to edit, and very powerful.

[devxpy]

There is already a mechanism to validate the settings.py file inside django.

The different context stuff can be handled by using env vars, and a nice python wrapper, like python-decouple.

[sametmax]

> There is already a mechanism to validate the settings.py file inside django.

It's not exposed, but it's very limited.

> The different context stuff can be handled by using env vars, and a nice python wrapper, like python-decouple.

It's just one of the way to do it. Go to a new project, they use a different way. The main benefit of Django is the fact that a Django project is well integrated, and you find similar conventions and structure from project to project, allowing to reuse the skill you learned and build an ecosystem of pluggable app.

[devxpy]

Just so we're on the same page, this is the validation I was referring to -

https://docs.djangoproject.com/en/2.1/topics/checks/

Standardization is always an issue, I guess. Env vars seem to be the norm in the community in my experience, whatever that's worth..

[sametmax]

Ah the stuff used for the password ?

I would be more of a fan of something like marshmallow, checking the whole thing.