Backwards compatibility is pain sometimes:
# We need backwards compatibility with code which spells it this way: # def my_view(): pass # my_view = cache_page(my_view, 123) # and this way: # my_view = cache_page(123)(my_view) # and this: # my_view = cache_page(my_view, 123, key_prefix="foo") # and this: # my_view = cache_page(123, key_prefix="foo")(my_view) # and possibly this way (?): # my_view = cache_page(123, my_view)
Comments:
Tell me about it. I once tried to write a universal view decorator base class to ease this very pain. It eventually worked, but all those edge cases had me wondering whether or not it was worth it in the first place.
That's definitely the growing pains when a project gets bigger, especially a great one like Django.
Maybe it's worth marking the decorator as deprecated and introducing one with more strict syntax requirements?
I guess the above example could be handled by accepting *args, popping the first callable and parsing the remainder but "there's more than one way to do it" is not supposed to be Python's motto :)
Maybe it's worth marking the decorator as deprecated and introducing one with more strict syntax requirements?
I guess the above example could be handled by accepting *args, popping the first callable and parsing the remainder but "there's more than one way to do it" is not supposed to be Python's motto :)
Was just looking at that today. Funny thing is, despite the measures taken to ensure backwards compatability, I spent 10 minutes trying to figure out why @cache_page on it's own wasnt working...
I also came across exactly the same part of the django source code just a couple of weeks ago and tought the same thing :)
Leave a comment: