See my comments above. Super curious about whether you think the complexity trade-off is worth it in general and if there are specific cases where it really makes sense.
Ah, you are the creator of returns. This explains. Good job introducing FP concepts to the Python crowd, thanks. It may be worth mentioning somewhere in the beginning that this is applicable to the development of any kind of software, not only Django apps.
It’s an interesting article, and I feel like I’d need to understand a lot more about how Django internals work to discern how adding an entire very complicated abstraction layer is the right trade-off in order to avoid setting an environment variable at runtime which causes a particular code path to be executed.
Does anybody who DOES understand the complexities presented want to talk about why they agree or disagree with the assertions in the article?
I probably know Django’s internals about as well as anyone.
First a refresher for those who aren’t familiar with what “Django settings” means.
In order to run at all, Django needs some configuration. It needs to know some basic stuff like whether it’s running in debug mode, as well as things like what kind of database you’re using and how to connect to it; what authentication sources you’re using; what applications you want to use; etc. There are two primary ways to do this:
Put your settings in a Python module, and set the path to that module in the environment variable DJANGO_SETTINGS_MODULE. The namespace of that module will become the key-value pairs of your Django settings.
Import and call django.settings.configure(), passing the desired settings. The keyword arguments to configure() will become the key-value pairs of your Django settings.
Django will then initialize itself from those settings, and be up and running. You can inspect the live settings by importing django.conf.settings, which will be an object exposing attributes that match the actual settings in use.
So I sympathize with not wanting to stick this particular thing in the settings. Django’s settings aren’t meant for things that might change while running; they’re meant for supplying the configuration needed to get your deployment of Django into a running state, and really want to be treated as static once it’s initialized. But because it’s there, always just a quick import away for any application, people do have a tendency to put all sorts of other stuff in there and then they come up with a bunch of different ways to try to make settings safely mutable at runtime in order to allow changing the stuff they’ve put in there.
For this specific article’s case, I personally would not do what the author did. The use case seems to be a piece of data that wants to be persistent but also mutable and with the ability to look it up on demand. Historically, the place to put such a thing is in a database, or first in a database and then pull into a caching layer with timeout and invalidation logic to avoid doing a DB query every time (and most non-trivial deployments of anything, regardless of framework, end up using such a caching layer in some way, so they’re probably not adding it just for storing this one value).
But the author’s goal here seems to be to try to write Haskell in Python, or at least to show off the possibility of writing Haskell-like code in Python. Whether this is a particularly good example of that I’m not qualified to say; beyond a few very basic things I’m not conversant in Haskell (ML-family stuff being more my style for when I want to dabble in functional-oriented languages).
Thanks for the superb explanation of Django settings in context of this article!
For this specific article’s case, I personally would not do what the author did. The use case seems to be a piece of data that wants to be persistent but also mutable and with the ability to look it up on demand. Historically, the place to put such a thing is in a database, or first in a database and then pull into a caching layer with timeout and invalidation logic to avoid doing a DB query every time (and most non-trivial deployments of anything, regardless of framework, end up using such a caching layer in some way, so they’re probably not adding it just for storing this one value).
Bingo!
In my limited experience, anyone implementing dependency injection in non Java-like languages is usually over-compensating for something and I have yet to find an instance where the massive spike in code complexity is worth it.
It’s entirely possible I’m being super narrow minded here, and I’d love it if others with broader experience would chime in and let me know what I’m missing :)
I made a dependency injector for Python ages ago:
https://dyject.com/
The project I used it in switched to doing everything with a config file and I’ve never really maintained this thing … pretty sure no one uses it. 😅
See my comments above. Super curious about whether you think the complexity trade-off is worth it in general and if there are specific cases where it really makes sense.
Ah, you are the creator of returns. This explains. Good job introducing FP concepts to the Python crowd, thanks. It may be worth mentioning somewhere in the beginning that this is applicable to the development of any kind of software, not only Django apps.
It’s an interesting article, and I feel like I’d need to understand a lot more about how Django internals work to discern how adding an entire very complicated abstraction layer is the right trade-off in order to avoid setting an environment variable at runtime which causes a particular code path to be executed.
Does anybody who DOES understand the complexities presented want to talk about why they agree or disagree with the assertions in the article?
I probably know Django’s internals about as well as anyone.
First a refresher for those who aren’t familiar with what “Django settings” means.
In order to run at all, Django needs some configuration. It needs to know some basic stuff like whether it’s running in debug mode, as well as things like what kind of database you’re using and how to connect to it; what authentication sources you’re using; what applications you want to use; etc. There are two primary ways to do this:
DJANGO_SETTINGS_MODULE. The namespace of that module will become the key-value pairs of your Django settings.django.settings.configure(), passing the desired settings. The keyword arguments toconfigure()will become the key-value pairs of your Django settings.Django will then initialize itself from those settings, and be up and running. You can inspect the live settings by importing
django.conf.settings, which will be an object exposing attributes that match the actual settings in use.So I sympathize with not wanting to stick this particular thing in the settings. Django’s settings aren’t meant for things that might change while running; they’re meant for supplying the configuration needed to get your deployment of Django into a running state, and really want to be treated as static once it’s initialized. But because it’s there, always just a quick
importaway for any application, people do have a tendency to put all sorts of other stuff in there and then they come up with a bunch of different ways to try to make settings safely mutable at runtime in order to allow changing the stuff they’ve put in there.For this specific article’s case, I personally would not do what the author did. The use case seems to be a piece of data that wants to be persistent but also mutable and with the ability to look it up on demand. Historically, the place to put such a thing is in a database, or first in a database and then pull into a caching layer with timeout and invalidation logic to avoid doing a DB query every time (and most non-trivial deployments of anything, regardless of framework, end up using such a caching layer in some way, so they’re probably not adding it just for storing this one value).
But the author’s goal here seems to be to try to write Haskell in Python, or at least to show off the possibility of writing Haskell-like code in Python. Whether this is a particularly good example of that I’m not qualified to say; beyond a few very basic things I’m not conversant in Haskell (ML-family stuff being more my style for when I want to dabble in functional-oriented languages).
Thanks for the superb explanation of Django settings in context of this article!
Bingo!
In my limited experience, anyone implementing dependency injection in non Java-like languages is usually over-compensating for something and I have yet to find an instance where the massive spike in code complexity is worth it.
It’s entirely possible I’m being super narrow minded here, and I’d love it if others with broader experience would chime in and let me know what I’m missing :)