|django.utils.functional.cached_property||Daniele Procida||8/6/13 2:28 PM|
Is there any reason why django.utils.functional.cached_property should not be documented, so that it can easily be used?
I'd have a lot of use for it.
|Re: django.utils.functional.cached_property||Anssi Kääriäinen||8/7/13 12:16 AM|
+1 to documenting it.
|Re: django.utils.functional.cached_property||Marc Tamlyn||8/7/13 1:33 AM|
+1 to documenting it.
|Re: django.utils.functional.cached_property||Aymeric Augustin||8/7/13 1:57 AM|
2013/8/6 Daniele Procida <dan...@vurt.org>
Yes, it's stable enough.Is there any reason why django.utils.functional.cached_property should not be documented, so that it can easily be used?
The main drawback of the current implementation is that it's impossible to clear the cached value. That should be mentioned in the docs.
|Re: django.utils.functional.cached_property||Daniele Procida||8/7/13 5:10 AM|
*Where* would be a good place to mention this?
There doesn't seem to be a single place in the documents for "handy decorators you might like". Perhaps there should be, with links to <https://docs.djangoproject.com/en/dev/topics/http/decorators/> for example.
There's <https://docs.djangoproject.com/en/1.5/ref/utils/#module-django.utils.functional> of course, but no-one would actually find it there unless they were already looking for it.
|Re: django.utils.functional.cached_property||Russell Keith-Magee||8/7/13 4:31 PM|
On Wed, Aug 7, 2013 at 8:10 PM, Daniele Procida <dan...@vurt.org> wrote:
Better still -- if we're going to formalise this as a public API, lets update the implementation so that we *can* clear the cached value -- or at least document the method by which one would clear the cache. Lets not formalise a half-complete API :-)
And +1 -- I can't see any reason that this shouldn't be public API -- it's a common pattern.
One suggestion -- a new special topic guide on performance tweaking, just like we have for security. We've already got this page:
which is all about database optimisation -- this is a big part of optimising, but it's not the only story. A "performance" topic guide would give a chance to introduce value caching, template loading options (including cached templates), fast and slow session options, discussing how and when the database is hit, as well as little performance tweaks like the documented parts of utils.functional.
|Re: django.utils.functional.cached_property||Curtis Maloney||8/7/13 6:44 PM|
On 8 August 2013 09:31, Russell Keith-Magee <rus...@keith-magee.com> wrote:
I just ran some informal tests to compare it against my own "buffered_property" implementation, and "del x.foo" deletes the cached value just fine for me, as does "delattr(x, 'foo')". Next access calls the method again, as expected. Also "x.foo = 'test'" sets the value fine.
After our discussion on IRC today, Russ, I'm confident the current implementation functions as you expect.
Hmm... I think I might have a few ideas to throw into that pile :)
|Re: django.utils.functional.cached_property||Daniele Procida||8/8/13 4:40 AM|
On Thu, Aug 8, 2013, Russell Keith-Magee <rus...@keith-magee.com> wrote:<https://code.djangoproject.com/ticket/20877>
I'd like to take that on, if unless anyone else feels they should be responsible for it, since it will involve a certain amount of structural change in the documents.
|Re: django.utils.functional.cached_property||Russell Keith-Magee||8/8/13 6:18 AM|
As far as I'm concerned -- go for it. It's not like people are lining up to do a big rewrite of the docs; if you're volunteering, it's all yours.
|Re: django.utils.functional.cached_property||Łukasz Rekucki||8/8/13 9:59 AM|
I have some minor nitpicks:
1. Unlike the standard @property, the current implementation of
@cached_property doesn't allow for a docstring.
2. Calling `del obj.<cached_property_name>` before accessing the value
or more then once in a row throws an AttributeError.
Should I make a new ticket for that or just send a PR for the old one ?
|Re: django.utils.functional.cached_property||Florian Demmer||3/19/14 2:58 PM|
wow, that AttributeError is super annoying to handle... i'd apprechiate a patch for that if you have it already written!
|Re: django.utils.functional.cached_property||Curtis Maloney||3/19/14 3:53 PM|
How is it behaving any differently to a normal attribute?
I went through this a year or so ago with RKM - once the property is set, del will clear it, allowing you to affect the call again. But if it's unset, del will raise an AttributeError - just like any other attribute.
|Re: django.utils.functional.cached_property||Florian Demmer||3/20/14 3:43 AM|
On 2014-03-19 23:53, Curtis Maloney wrote:sorry, is that discussion online somewhere to read up on the reasoning?
let me be clearer about what i find could be improved. it's the first
half of Łukasz's 2:
- a @property cannot be deleted on the instance (you can on the class),
AttributeError, that's ok.
- a normal property can be deleted and if deleted *again* of course
raises an AttributeError. it's not there, you cannot delete it. also good.
- @cached_property raising when deleting *again* is therefore reasonable.
- what i found surprising for a second, was that it raises the error,
when it was never accessed. it makes sense technically speaking of
course. the instance attribute just isn't set when the decorated method
so seeing @cached_property as a mix of actual attribute and @property,
the behavior makes sense. seeing it as a caching mechanism not so much imho.
so what do i want?
maybe just a mention of the "never accessed" behavior in
on the other hand i'd like to have safe, clean cache invalidation
without lots of boilerplate every time i need to invalidate a
... and so i was curious about a patch doing something else, if there
were one already written but just not submitted.