You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current implementation, PUBLIC and _PRIVATE are accessible fromdjango.conf.settings via MY_APP_PUBLIC, whereas MY_APP__PRIVATE. My idea is to make _PRIVATE inaccessible as it is considered to be private.
I see two ways we could implement this.
Treat names prefixed with an underscore as private (as in the example above; this is Python's way...). However, the issue with this approach is that some linters may complain that other parts of the codebase use private attributes (e.g. Ruff, the rule SLF001).
Add an extra attribute to Meta (private, let us say) that could be a list of names for private settings.
Hi @paduszyk. Django settings doesn't really have any concept of private settings. AppConf already scopes settings to a particular app, but I'm not sure going further than that is really in scope here.
@carltongibson OK 👍🏻 Maybe the name "private settings" is misleading... By private I meant "seen" only by the AppConf instance. You can access them from myapp.conf.settings, but not from django.conf.settings.
Hi 👋🏻
I'd to share an idea for private settings, a new feature for the
django-appconf
.Consider the following example:
In the current implementation,
PUBLIC
and_PRIVATE
are accessible fromdjango.conf.settings
viaMY_APP_PUBLIC
, whereasMY_APP__PRIVATE
. My idea is to make_PRIVATE
inaccessible as it is considered to be private.I see two ways we could implement this.
Meta
(private
, let us say) that could be a list of names for private settings.This could be useful (and elegant/Pythonic IMHO) for adding configurations specific to the configured app. What's your opinion?
If you find this idea interesting, I can open a PR.
The text was updated successfully, but these errors were encountered: