Re: Redis cache support in core

s but would >> be shipped outside of Django. >> >> The benefit with 3rd party packets is their shorter release cycle. Which, >> in the context of django-redis could be beneficial . >> >> /Markus >> >> On Fri, Jun 21, 2019, at 2:43 PM, 'Ivan Anishchuk'

Re: Redis cache support in core

I wouldn't say it's that complicated a setup. It would require a single settings snippet -- just like the ones for other backends -- and, I guess, a link to django-redis docs for more details (if django-redis is what we recommend), maybe a quick explanation of what is CLIENT_CLASS and other

Re: Redis cache support in core

How about making one of the third-party packages an optional dependency? Celery, for example, does that: you can just install celery[redis] without having to figure out what other packages you need to enable redis support. Ivan. On Wed, Jun 19, 2019 at 6:44 AM Josh Smeaton wrote: > There are

Re: Proposal to format Django using black

f some of the formatting > choices are not agreeable. > > On Wed, 17 Apr 2019 at 03:38, 'Ivan Anishchuk' via Django developers > (Contributions to Django itself) > wrote: > >> My two cents: black's mostly ok but I'm against any auto-formatting. Code >> style is much

Re: Proposal to format Django using black

My two cents: black's mostly ok but I'm against any auto-formatting. Code style is much more than whitespace arrangement, it requires looking, creative thinking, judging, and sometimes actually compromising rules and looks for readability while the usual attitude with such tools is "I have this

Re: Proposal to re-open #27017 (updating only dirty fields in save())

While I'm not sure I have any particular suggestion for this, the problem is important enough for a few of the projects I'm maintaining. I have implemented more than a few custom save() methods, post_init/pre_save/post_save signals and complicated ways of setting update_fields and acting on their

Re: revisiting the Python version support policy

Yep, I'm definitely in favor of dropping 3.5 early and using all the nice features extensively. Especially type annotations. All projects I work on use 3.6 or later for quite some time now, whatever debian guys might feel about stability. Ivan. On Wed, Jan 23, 2019 at 12:16 PM Josh Smeaton

Re: A faster paginator for django

Note: I'm only covering postgres here but the idea is pretty universal. Good pagination starts with good sorting, so I'd suggest starting with having a good primary key. Integer PK could be enough, could be not quite (custom generator + postgres uuid field would be the next logical choice for me,

Re: Make `raw_id_fields` the default functionality in the admin

Well, I did personally encounter this issue more than a couple times on several projects. In most cases simply switching to raw id or read only where required works fine however it does add additional maintenance overhead for projects that started small and at some point database grows and some

Re: Standalone is_safe_url() function

Yeah, it can be pretty useful at times, for example, in api clients. I used it quite a few times and had no idea it's not a part of the public api. Ivan. On Sun, Oct 28, 2018 at 12:29 PM Adam Johnson wrote: > I needed that functionality on another project that doesn't use Django at >> all. >>

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

(Sorry, accidental send.) Consider adding a custom __call__ method to your manager class that would only accept values for pk lookup, nothing else. That way you can save four additional characters (qs(123) vs qs.get(id=123)) and that would be something I'm not against seeing in django, provided

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

Not closely related, but what about composite keys? I think having such an implicit arg interpretation would make it much more complicated to use, say, a combination of charfield and integerfield as your key (primary or foreign doesn't matter): what does .get(('string', 123)) mean?