Example of prototype code.
Example of prototype code.
Released dj-typed-settings with some different approaches to help use and write #Django settings. 🚀
- Django system check to validate setting types at runtime.
- Setting `defaults` for IDE autocomplete
- `DATABASE`, `CACHES`, `TEMPLATE`, and `AUTH_PASSWORD_VALIDATOR` helper methods for dictionary settings
- Typed access to settings
- Automatically fix up setting types at runtime, e.g. DEBUG="True" -> DEBUG=True
🛠️ https://github.com/adamghill/dj-typed-settings
📦 https://pypi.org/project/dj-typed-settings/
@adamghill did you look at protocol classes? Can you have used those instead of data classes?
@farhanaliraza I think protocols would be theoretically faster (because nothing gets instantiated), but I’d have to maintain a bunch of other things that dataclasses gives me “for free”. I did spend a bunch of time looking into TypedDicts for complex settings, but decided against that as well.
@farhanaliraza One thing in core that would be helpful (I think) would be adding types/docstrings to https://github.com/django/django/blob/main/django/conf/global_settings.py. Right now, I parse the module to figure them out, but having actual annotations to inspect would be cleaner.
A settings dataclass or protocol in core would be better, but that seems like an uphill battle.
Python typing support for modules is not ideal. `from dj_typed_settings.defaults import *` feels hacky, but I don't think there is another way without an LSP.
@adamghill @farhanaliraza you could add an informed comment to the new-features issue on all this. (It might be number 11)