cache.has_key() doesn't do the same thing as "key in cache"

[Marty Alchin]

In [source:django/trunk/django/core/cache/backends/base.py django.core.cache.backends.base.BaseCache], has_key() is defined as a method, while __contains__ is simply an alias for it. Individual backends override has_key() to be more efficient, but __contains__ is left alone, so it's still an alias for the base function, which unfortunately means that the two end up with different implementations. This is generally fine, but shows itself when None is stored in the cache, which is a potentially useful situation.

>>> from django.core.cache import cache
>>> cache.set('test', None)
>>> cache.has_key('test')
True
>>> 'test' in cache
False

[Marty Alchin]

Fixed __contains__ to always call has_key() and added tests to verify they work the same way.

[Marty Alchin]

For what it's worth, I tested with with locmem, but since key in cache always calls BaseCache.__contains__, it actually doesn't matter what backend is used. There's also probably a case to be made that BaseCache.has_key() itself is buggy, since it could specify a default instead of assuming the default will always be None, but since all the backends override it, it's not a concern unless a custom backend (which is only recently possible) doesn't supply its own has_key().

[Malcolm Tredinnick]

(In [8084]) Fixed #7967 -- Make sure the contains method in the cache backends call the
right has_key() method for the subclass. Patch from Marty Alchin.

[Jacob]

Milestone 1.0 deleted