On Jul 26, 10:02 am, Tobias McNulty <tob...@caktusgroup.com> wrote: > If such reusable code needs to cache things forever, which sounds perfectly > reasonable to me, I'd still rather not co-opt "0" to mean "forever" in all > cases. Each backend that supports caching with no timeout could easily > offer a class attribute, such as "TIMEOUT_FOREVER", that indicated how to > set the timeout in these cases.
I'm not sure I see the problem with co-opting 0, since it already has (or should have) that meaning on the most commonly-used backend, and doesn't really have any other sensible meaning as a cache timeout value. But the proposed class attribute is fine too. > Rejecting a particular subset of cache keys is also not the greatest analogy > to co-opting configuration values. :-) The common thread, of course, is making it possible to write reusable caching code without special-casing particular backends. Carl -- 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.
