> and suggests otherwise). It might not be too difficult to add support > for an optional timeout, although the error checking requires a lot of > care.
I think that's the main problem. Since arguments to {% cache %} aren't named, it doesn't seem possible to differentiate {% cache 500 key1 key2 %} from {% cache user.id key1 key2 %}. In the first case, 500 represents a timeout. In the second case, user.id might resolve to 500 and represent a _key_ rather than a timeout. I'm not sure of an elegant way to deal with this. I'll probably stick with setting a large constant in a context_processor and using that as the "effectively expire never" time. I'd have to use a similar trick when using the low-level cache API, anyway. Thanks, Nick --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---