#35609 closed Cleanup/optimization (invalid)
RemovedInDjango50Warning communications with changing the default USE_TZ
Reported by: | Vladislav Dobrovolskiy | Owned by: | |
---|---|---|---|
Component: | Core (System checks) | Version: | 4.2 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Good afternoon
When starting Django, we found a Warning that cannot be corrected (it continues to be displayed in the logs and terminal). This happens because the settings are initialized more than once and the condition for displaying the warning is incorrect, in my opinion. Example from code:
self._explicit_settings = set() for setting in dir(mod): if setting.isupper(): setting_value = getattr(mod, setting) if setting in tuple_settings and not isinstance( setting_value, (list, tuple) ): raise ImproperlyConfigured( "The %s setting must be a list or a tuple." % setting ) setattr(self, setting, setting_value) self._explicit_settings.add(setting) if self.USE_TZ is False and not self.is_overridden("USE_TZ"): warnings.warn( "The default value of USE_TZ will change from False to True " "in Django 5.0. Set USE_TZ to False in your project settings " "if you want to keep the current default behavior.", category=RemovedInDjango50Warning, )
When first initialized, dir(mod) contains
['__annotations__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__']
During the second initialization, the project settings are already. This doesn't affect how django works, but it can be confusing. It might be worth replacing the warning condition:
def is_overridden(self, setting): return setting in self._explicit_settings and self._explicit_settings
Because the multitude self._explicit_settings may be empty due to a condition if setting.isupper():
Change History (3)
follow-up: 2 comment:1 by , 5 months ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
comment:2 by , 5 months ago
Replying to Sarah Boyce:
Hi Vladislav,
So although Django 4.2 is on extended support (which means we only release updates for security fixes and would not release an update to fix this specific case), the helperis_overridden
is still in use in the codebase and we could fix this if required.
You're right that the settings are initialized more than once. For this to be an issue,_explicit_settings
needs to be empty on the first initialization which I don't know how to reproduce.
Can you share details on your settings file? Or some further instructions on how to replicate this?
Hi, thanks for the quick response. Now I spent a little time checking and realized that the problem only appears in my environment and is not reproduced in a clean project.
P.S. I also tried to move the problem to a clean project, but so far I have not succeeded. Perhaps you can close the request (it does not relate to django directly).
comment:3 by , 5 months ago
Resolution: | needsinfo → invalid |
---|
Thank you for the follow up Vladislav 👍 closed the ticket
Hi Vladislav,
So although Django 4.2 is on extended support (which means we only release updates for security fixes and would not release an update to fix this specific case), the helper
is_overridden
is still in use in the codebase and we could fix this if required.You're right that the settings are initialized more than once. For this to be an issue,
_explicit_settings
needs to be empty on the first initialization which I don't know how to reproduce.Can you share details on your settings file? Or some further instructions on how to replicate this?