>
> But it is not possible unless we directly override the
> password_validation classes and this is an extra and dirty work.
I don't think this work is dirty!
We generally prefer to avoid extra settings (and sub-settings) where
possible. The settings file should be clear, and not do what code
This can currently be achieved with:
qs.annotate(lowername=Lower("name")).filter(lowername__in=['text'])
You’re free to add “iin” to your projects, but I'm not sure it's valuable
enough to add to Django.
Some years ago, there was an idea to allow python expressions to generate
ORM filters, that
The speckenv example highlights the problems when using `literal_eval`:
A=[] will parse as list but A=[a] will parse as string again (if I read the
code correctly). This ambiguity makes it really hard to explain. When using
`literal_eval` one imo has to be consistent and don't fall back to a
Hi Igor,
The sort of thing I had in mind was:
{% with cache_timeout=request.user.is_authenticated|yesno:"0,500" %}
{% cache cache_timeout sidebar %}
...
{% endcache %}
{% endwith %}
Kind Regards,
Carlton
On Wednesday, 12 October 2022 at 17:17:57 UTC+2
On Tue, Nov 1, 2022 at 10:34 AM Florian Apolloner
wrote:
> Right, that would work. I am wondering though if we want to go all in on a
> typed config object like that or in a first step only have a simple API
> like `config.get('DEBUG', cast=bool)`.
>
>
I found a neat trick in a 12factor library
config.get is how python-decouple works which is what I use for config and
deployment settings.
On Tuesday, 1 November 2022 at 09:34:15 UTC f.apo...@gmail.com wrote:
> Right, that would work. I am wondering though if we want to go all in on a
> typed config object like that or in a first step
