cache_page used as 2.4 decorator with time
Graham King
seem to work when passing a time with the python 2.4 syntax.
This works:
@cache_page
def index(request):
do stuff
As does this:
def index(request):
do stuff
index = cache_page(index, 60 * 60)
But this doesn't:
@cache_page(60 * 60):
def index(request):
do stuff
yet that is the example given here:
http://www.djangoproject.com/documentation/cache/#the-per-view-cache
It seems to pass the time as the first parameter, where the function
should be.
Has anyone else had this problem ? It might well be my limited
understanding of decorators, or simply a change needed in the docs.
Thanks,
Graham.
Malcolm Tredinnick
The docs don't look right. In python 2.4, this:
@decor(x)
def g(y):
....
is equivalent to g = decor(x)(g), not g = decor(g, x). I'll have a look
at what's going on in the code (cache decorators are created in a
slightly tricky fashion in Django). For the time being, don't do that.
Regards,
Malcolm
Malcolm Tredinnick
OK, now I have a nose bleed: reading decorator code is not always fun
with all the factory functions that are nested there.
As I suspected, there's no chance of the @cache_page(60*60) version
working. It's fairly fiddly to right robust decorators that can
optionally take arguments, because you have to try and detect if the
first argument is a callable and behave differently if it isn't.
I'm not sure what the maintainers would want to do here (my crystal ball
is in the shop today), but one solution would be to create a second
decorator that would always require arguments. So we would have
@cache_page
def index(...):
...
and
@custom_cache_page(cache_timeout = 60 * 60)
def index(...):
...
Alternatively, they may wish to bite the bullet and write a smarter
version of decorator_from_middleware() that can accept optional
parameters. That is not impossible, but the code starts to get pretty
hard to understand after a while.
Cheers,
Malcolm