Re: Redis cache support in core

2019-06-21 Thread 'Ivan Anishchuk' via Django developers (Contributions to Django itself) 
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
options. While it would add some maintenance burden (occasionally checking
whether any breaking changes were introduced in the 3rd party package that
require updating settings) it's still way easier than adding a backend to
django core.

While I agree with others about redis being popular and adding such a
backend in django being a good idea (I would love if that happened) I
understand the reasons for not doing it. A recommendation of a 3rd party
package + setup documentation, on the other hand, is pretty simple thing to
do.

If we want, it's also not very hard to provide
`django.core.cache.backend.redis.Redis Cache` that depends on django-redis
and is an alias for `django_redis.cache.RedisCache` -- it's basically the
way it works with DB backends, I don't see why it wouldn't be a good idea
for cache as well.

Ivan.

On Thu, Jun 20, 2019, 04:02 Josh Smeaton  wrote:

> Celery explicitly document their integration with Redis though. I don't
> think we want to take over documenting the setup of a 3rd party package in
> Django.
>
> On Thursday, 20 June 2019 11:00:27 UTC+10, Ivan Anishchuk wrote:
>>
>> 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 already several 3rd party packages that implement redis as a
>>> django cache backend, for example https://github.com/niwinz/django-redis
>>>
>>> We already have a base class for cache backends - and several
>>> implementing it (such as memcache). I don't think there's much benefit
>>> taking on another backend when it's already got very good support as an
>>> external package.
>>>
>>>
>>> On Tuesday, 18 June 2019 01:14:25 UTC+10, Dulmandakh Sukhbaatar wrote:

 Hello,

 I would like to work on Redis support in core, and I would like to
 discuss proper solution for that.

 Redis is getting so popular and almost every modern backend stack uses
 it someway, therefore I think that supporting it as a cache backend in core
 would make Django more appealing. A solution I'm proposing is to extract
 base KV backend from current Memcached and extend it for both Memcached and
 Redis, and this won't add many new code to the core. Also we'll have base
 class for KV storage backends.

 Thanks.

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-d...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/bdb84d20-0489-4ecd-b198-fa5878f5c617%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/335b087c-801a-452b-a5b3-a9711e4a00b8%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADPNjZ5rU9wxFg_FCohJaO9%3DaA8wZ1PSyhx580BUZ6-Xr2BVDA%40mail.gmail.com.
For more options, visit https://groups.google

Re: Redis cache support in core

2019-06-21 Thread Markus Holtermann 
Hi all,

may I suggest that django-redis may be "promoted" to an official Django package 
under the Django GitHub organization? This would follow 
https://github.com/django/deps/blob/master/final/0007-official-projects.rst . 
The package would be pointed out explicitly in the Django docs 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' via Django developers  
(Contributions to Django itself) wrote:
> 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 options. While it would add some maintenance burden 
> (occasionally checking whether any breaking changes were introduced in 
> the 3rd party package that require updating settings) it's still way 
> easier than adding a backend to django core.
> 
> While I agree with others about redis being popular and adding such a 
> backend in django being a good idea (I would love if that happened) I 
> understand the reasons for not doing it. A recommendation of a 3rd 
> party package + setup documentation, on the other hand, is pretty 
> simple thing to do.
> 
> If we want, it's also not very hard to provide 
> `django.core.cache.backend.redis.Redis Cache` that depends on 
> django-redis and is an alias for `django_redis.cache.RedisCache` -- 
> it's basically the way it works with DB backends, I don't see why it 
> wouldn't be a good idea for cache as well.
> 
> Ivan.
> 
> On Thu, Jun 20, 2019, 04:02 Josh Smeaton  wrote:
> > Celery explicitly document their integration with Redis though. I don't 
> > think we want to take over documenting the setup of a 3rd party package in 
> > Django.
> > 
> > On Thursday, 20 June 2019 11:00:27 UTC+10, Ivan Anishchuk wrote:
> >> 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 already several 3rd party packages that implement redis as a 
> >>> django cache backend, for example https://github.com/niwinz/django-redis
> >>> 
> >>> We already have a base class for cache backends - and several 
> >>> implementing it (such as memcache). I don't think there's much benefit 
> >>> taking on another backend when it's already got very good support as an 
> >>> external package.
> >>> 
> >>> 
> >>> On Tuesday, 18 June 2019 01:14:25 UTC+10, Dulmandakh Sukhbaatar wrote:
>  Hello,
>  
>  I would like to work on Redis support in core, and I would like to 
>  discuss proper solution for that.
>  
>  Redis is getting so popular and almost every modern backend stack uses 
>  it someway, therefore I think that supporting it as a cache backend in 
>  core would make Django more appealing. A solution I'm proposing is to 
>  extract base KV backend from current Memcached and extend it for both 
>  Memcached and Redis, and this won't add many new code to the core. Also 
>  we'll have base class for KV storage backends.
>  
>  Thanks.
> 
> >>>  -- 
> >>>  You received this message because you are subscribed to the Google 
> >>> Groups "Django developers (Contributions to Django itself)" group.
> >>>  To unsubscribe from this group and stop receiving emails from it, send 
> >>> an email to django-d...@googlegroups.com.
> >>>  To post to this group, send email to django-d...@googlegroups.com.
> >>>  Visit this group at https://groups.google.com/group/django-developers.
> >>>  To view this discussion on the web visit 
> >>> https://groups.google.com/d/msgid/django-developers/bdb84d20-0489-4ecd-b198-fa5878f5c617%40googlegroups.com
> >>>  
> >>> .
> >>>  For more options, visit https://groups.google.com/d/optout.
> 
> >  -- 
> >  You received this message because you are subscribed to the Google Groups 
> > "Django developers (Contributions to Django itself)" group.
> >  To unsubscribe from this group and stop receiving emails from it, send an 
> > email to django-developers+unsubscr...@googlegroups.com.
> >  To post to this group, send email to django-developers@googlegroups.com.
> >  Visit this group at https://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/335b087c-801a-452b-a5b3-a9711e4a00b8%40googlegroups.com
> >  
> >

Re: Thoughts on Django Model attribute (descriptor) inheritance.

2019-06-21 Thread Carlton Gibson 
Hi All

Can I ask folks to have a look at this please? 

Ticket is: https://code.djangoproject.com/ticket/30427
PR is: https://github.com/django/django/pull/11337

The original change that introduced the current behaviour is 
https://github.com/django/django/pull/6491/files#diff-bf776a3b8e5dbfac2432015825ef8afeR699

*Question: *What was the reason for this comment: 

# Don't override classmethods with the descriptor. This means that
# if you have a classmethod and a field with the same name, then

#such fields can't be deferred (we don't have a check for this).


In case it rings any bells...

PR there was called:

"Replaced dynamic classes with non-data descriptors for deferred 
instance loading."

Related mailing list discussion: 
https://groups.google.com/forum/#!msg/django-developers/BDAlTyJwQeY/Fh2Qy07cAQAJ

Thanks. 
Carlton

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/94d1f059-8cb2-435b-be52-66d3ae1a4721%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Thoughts on Django Model attribute (descriptor) inheritance.

2019-06-21 Thread Ryan Hiebert 
I'm not sure what the reasoning was, but it does ring some bells for me, as
I think this sounds like the case of the of the issue discovered in
https://code.djangoproject.com/ticket/28198. Hopefully that's a correct
connection, and I'm not sending you chasing something irrelevant to your
current task.

On Fri, Jun 21, 2019 at 8:39 AM Carlton Gibson 
wrote:

> Hi All
>
> Can I ask folks to have a look at this please?
>
> Ticket is: https://code.djangoproject.com/ticket/30427
> PR is: https://github.com/django/django/pull/11337
>
> The original change that introduced the current behaviour is
>
> https://github.com/django/django/pull/6491/files#diff-bf776a3b8e5dbfac2432015825ef8afeR699
>
> *Question: *What was the reason for this comment:
>
> # Don't override classmethods with the descriptor. This means that
> # if you have a classmethod and a field with the same name, then
>
> #such fields can't be deferred (we don't have a check for this).
>
>
> In case it rings any bells...
>
> PR there was called:
>
> "Replaced dynamic classes with non-data descriptors for deferred
> instance loading."
>
> Related mailing list discussion:
> https://groups.google.com/forum/#!msg/django-developers/BDAlTyJwQeY/Fh2Qy07cAQAJ
>
> Thanks.
> Carlton
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/94d1f059-8cb2-435b-be52-66d3ae1a4721%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHR-mhQGneh-bjUV6Oa_DubVVDOC2jc_CWaBoR6LPVdZTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Thoughts on Django Model attribute (descriptor) inheritance.

2019-06-21 Thread Carlton Gibson 
Hi Ryan, 

That does look related, yes. 

On Friday, 21 June 2019 15:47:53 UTC+2, Ryan Hiebert wrote:
>
> Hopefully that's a correct connection, and I'm not sending you chasing 
> something irrelevant to your current task.
>

TBH any pointers are handy at this stage in the game. 🙂

Thanks! 

(Still interested in hearing what original thoughts were if anyone _can_ 
dig them up in the grey-matter...)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c35f0b82-5b82-4cfb-bd98-4756ee93dea9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.