On Sun, Feb 21, 2010 at 11:22 PM, Jacob Kaplan-Moss <ja...@jacobian.org> 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 addition" so it can go in for 1.2. If you can > work up a patch I'll be happy to review.
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 process right now for 1.2: 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. 2. The memcached backend in Django should look first for the correct library, and fall back to the old one as needed. 3. When falling back to the old memcached library, 1.2 should raise PendingDeprecationWarning; 1.3 should promote that to a DeprecationWarning and 1.4 should remove the support entirely. Anything and everything else being discussed is out of scope for 1.2 and must wait for the 1.3 feature proposal window. > I have a couple of questions: > >> A slight rework of the memcache client that implements a base class >> which resembles the current Django 1.1 memcache client. Anything that >> implements the current CACHE_BACKEND setting "memcached://server:port" >> would use this base class. Throw a deprecation warning if the >> cmemcache library is being used in this way. > > I'm not quite clear how what you're talking about here. You want to > raise a deprecation warning about anyone who uses "memcached://" > instead of something new-style? > >> Additionally, add explicit subclasses for pylibmc and python- >> libmemcache, so if "pylibmc://server:port", "memcached://server:port? >> lib=pylibmc" or some variety there of controls what subclass gets >> used. > > I discussed "memcached+pylibmc://", "memcached+cmemcache" etc. It's a > bikeshed, though, and if you write the patch you can paint it. > >> Forcing the user to be explicit on what library they use could be >> added later, although I don't know if it's necessary. > > "In the face of ambiguity, refuse the temptation to guess." > > We've violated this rule by guessing once; I'd like to switch to > *just* use python-memcached, and force anyone who wants anything else > (including cmemcached) to be explicit. We can't do that in 1.2, > though, so maybe this is the warning you were talking about? i.e. warn > if cmemcached is chosen automatically? > >> Pylibmc and python-memcache have almost identical API characteristics >> (from pylibmc's docs: "pylibmc‘s interface is intentionally made as >> close to python-memcached as possible, so that applications can drop- >> in replace it."), and only differ in pylibmc's flexibility of memcache >> behaviors and their hashing method. (See >> http://sendapatch.se/projects/pylibmc/#behaviors >> and >> http://sendapatch.se/projects/pylibmc/#differences-from-python-memcached). >> The subclass should end up being fairly lightweight. > > Please make sure if you do this that there's a mechanism to use > pylibmc's consistent hashing -- it's the main reason to switch to > pylibmc. Actually, the more I think about it, if you're using pylibmc > then consistent hashing should be the *default*. > > Thanks for getting this started! > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
