On Mar 1, 5:27 pm, Jacob Kaplan-Moss wrote:
> Also, a step 2.5, if you'd like, would be to write a tiny app on pypi
> that enabled the use of pylibmc via an external cache backend. We
> could point to it in the deprecation notes when we explain why
> cmemcache is being deprecated.
See http://gist
On Sun, Feb 28, 2010 at 11:40 PM, Jacob Burch wrote:
> Thanks all for the helpful discussion here. From the sounds of thing,
> my course of action will be:
>
> 1) Get a patch that throws a FutureDeprecationWarning when cmemcache
> is used + Change of the docs to note the coming deprecation of
> cm
Thanks all for the helpful discussion here. From the sounds of thing,
my course of action will be:
1) Get a patch that throws a FutureDeprecationWarning when cmemcache
is used + Change of the docs to note the coming deprecation of
cmemcache
2) Begin working on a more involved patch that hopefully
On Tue, Feb 23, 2010 at 2:41 AM, Mike Malone wrote:
> > At this point in the release process, I'm not sure we can do
> > everything that's being talked about in this thread. Given that we're
> > feature-frozen and that there's no way we can spring a completely new
> > cache backend on people at t
> At this point in the release process, I'm not sure we can do
> everything that's being talked about in this thread. Given that we're
> feature-frozen and that there's no way we can spring a completely new
> cache backend on people at the last minute, here's what's possible
> within our release pr
On 2/22/10 2:09 PM, James Bennett wrote:
1. Specifying memcached as the cache backend continues using the same
"memcached://" scheme as it always has. There is no way we can change
that in the 1.2 timeframe.
I concur in that this needs more thought before rushing a change like that.
2. The
On Sun, Feb 21, 2010 at 11:22 PM, Jacob Kaplan-Moss wrote:
> A bit more background: I've been told at PyCon that cmemcached is
> unmaintained and deliberately being left to die in favor of pylibmc.
>
> Because of that I'm +1 on your proposal, and I'll argue that we not
> consider it a "feature add
a huge +1 on this, having been bitten by cmemcache multiple times. I know
this will be controversial, and probably both totally unrelated but thought
I'd bring up some other issues we have with caching:
1. As we keep adding more memcache it gets increasingly painful, some form
of consistent hashin
On Sun, Feb 21, 2010 at 8:46 PM, Rajiv Makhijani wrote:
> I recently implemented a custom caching backend to add support for pylibmc
> on a large site due to issues with cmemcache.
>
> For the most part the 'pylibmc' APIs are the same as 'python-memcached' and
> 'cmemcache'.
>
> One changed behavi
I recently implemented a custom caching backend to add support for
pylibmc on a large site due to issues with cmemcache.
For the most part the 'pylibmc' APIs are the same as 'python-memcached'
and 'cmemcache'.
One changed behavior I ran into with 'pylibmc' that I did not experience
with othe
On Sun, Feb 21, 2010 at 8:32 PM, Jacob Burch wrote:
> This is in regards to Tickets #11675 and #12427.
A bit more background: I've been told at PyCon that cmemcached is
unmaintained and deliberately being left to die in favor of pylibmc.
Because of that I'm +1 on your proposal, and I'll argue th
This is in regards to Tickets #11675 and #12427.
Review of the problems
-
There are two overarching problems with Django's current
implementation of memcached as a backend:
A) The import tree method of picking the appropriate library (if I
have cmemcache use it, if not use python-memcache, i
12 matches
Mail list logo
