feature suggestion: allow registering default settings to LazySettings

Django Internals Mentorship
1

hi :waving_hand:

so something i commonly see in django related packages is this pattern:
getattr(settings, "MY_SETTING", something_default)

while this works, it’s ugly and repetitive

I’ve been playing around with the class and i think a register functionality is a good option for this

a method would be added to the LazySettings class, let’s call it register() for now, which accepts default settings, which could be a python file, or a class
then it adds those settings to it’s attributes, ofc it skips the setting if the user has defined it

then we can simply call settings.MY_SETTING without fearing that something would break

also having a file or class for default settings makes it easier to document them

one thing to note is, in this way the package maintainer needs to ensure python reads the registration before they try to access the setting

am eager to hear what you think about this :raising_hands:

2

We often include a file called app_settings.py that has declarations such as:

from django.conf import settings

MY_SETTING = getattr(settings, “MY_SETTING”, “a default”)

And just use from app_settings import MY_SETTING around the rest of the app instead.

I don’t personally think it’s something worth adding to core, tbh!

1 Like
3

I think you’ll find a lot of folks will agree with me that this is neither ugly nor repetitive :slight_smile:

Not ugly because imho it’s pythonic. Not repetitive because … what’s being repeated other than “I want attribute x from y with a default of z”? :man_shrugging:

The usual suggestion here is to create something and pitch it to the folks that maintain django-extensions. If it becomes a popular feature that is a sign that it’s a candidate for inclusion into Django… until then its cost-benefit is speculative :slight_smile:

2 Likes
4

hi :waving_hand:
thanks for your feedback

in my eyes django.conf.settings is the object where all settings in a normal project should reside

in this approach a second settings must be added for each project to read from, now it might not a be a big deal, but i feel like the full potential of the settings is not used

i should have been more clear on what i mean
this code already exists in django, the first loop in django.conf.Settings.__init__ is doing this

the proposal is to move that to a separate method, so it’s a not a one time thing anymore

let me know if this makes sense :folded_hands:

5

hi👋
these make sense, because tbh what we have is not a bad thing
but what I’m seeing is that it can be better

well it’s definitely in python :grinning_face_with_smiling_eyes:
I’d argue dot notation is the more pythonic way, specially when we can achieve it rather easily

I’m not sure how something this deeply inside django would be a good fit for django-extensions

as i mentioned in my previous response, this functionality already exists in django
I’m just suggesting that we move it to a dedicated method so it can be used more than once

hope this makes sense :folded_hands:

6

This is true, for a normal project. But you’re specifically talking about packages, and all their required settings and defaults. As you pointed out, every package includes some form of the getattr method already. I don’t think the method of app_settings.py that I showed above is a pattern that needs fixing. If anything, it’s better than your proposed idea because:

  • import order is irrelevant, your concern about maintainers having to ensure their settings module is imported first is not an issue with it
  • every setting relevant to the package is defined in one definitive place, and you can be certain that if django.conf.settings is accessed in the package codebase elsewhere, it’s not a setting related to the package.

Just my two cents :slight_smile:

1 Like