django.utils.functional.cached_property

[Daniele Procida]

Is there any reason why django.utils.functional.cached_property should not be documented, so that it can easily be used?

<https://code.djangoproject.com/ticket/20870>

I'd have a lot of use for it.

Daniele

[Anssi Kääriäinen]

+1 to documenting it.

[Marc Tamlyn]

+1

+1 to documenting it.

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Aymeric Augustin]

2013/8/6 Daniele Procida <dan...@vurt.org>

Is there any reason why django.utils.functional.cached_property should not be documented, so that it can easily be used?

<https://code.djangoproject.com/ticket/20870>

 

Yes, it's stable enough.

The main drawback of the current implementation is that it's impossible to clear the cached value. That should be mentioned in the docs.

-- 
Aymeric.

[Daniele Procida]

*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.

Daniele

[Russell Keith-Magee]

On Wed, Aug 7, 2013 at 8:10 PM, Daniele Procida <dan...@vurt.org> wrote:

On Wed, Aug 7, 2013, Aymeric Augustin <aymeric....@polytechnique.org> wrote:

>2013/8/6 Daniele Procida <dan...@vurt.org>
>
>> Is there any reason why django.utils.functional.cached_property should not
>> be documented, so that it can easily be used?
>>
>> <https://code.djangoproject.com/ticket/20870>
>>
>
>Yes, it's stable enough.
>
>The main drawback of the current implementation is that it's impossible to
>clear the cached value. That should be mentioned in the docs.

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.

*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.

One suggestion -- a new special topic guide on performance tweaking, just like we have for security. We've already got this page:

https://docs.djangoproject.com/en/dev/topics/db/optimization/

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.

Russ %-)

  

[Curtis Maloney]

On 8 August 2013 09:31, Russell Keith-Magee <rus...@keith-magee.com> wrote:

On Wed, Aug 7, 2013 at 8:10 PM, Daniele Procida <dan...@vurt.org> wrote:

On Wed, Aug 7, 2013, Aymeric Augustin <aymeric....@polytechnique.org> wrote:

>The main drawback of the current implementation is that it's impossible to
>clear the cached value. That should be mentioned in the docs.

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 :-)

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.

 

One suggestion -- a new special topic guide on performance tweaking, just like we have for security. We've already got this page:

https://docs.djangoproject.com/en/dev/topics/db/optimization/

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.

Hmm... I think I might have a few ideas to throw into that pile :)

 

Russ %-)

  

[Daniele Procida]

On Thu, Aug 8, 2013, Russell Keith-Magee <rus...@keith-magee.com> wrote:

>One suggestion -- a new special topic guide on performance tweaking

<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.

Daniele

[Russell Keith-Magee]

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.

Russ %-) 

 

[Łukasz Rekucki]

Hi,

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 ?

--
Łukasz Rekucki

[Florian Demmer]

wow, that AttributeError is super annoying to handle... i'd apprechiate a patch for that if you have it already written!

thanks,
Florian

[Curtis Maloney]

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.

--

Curtis

[Florian Demmer]

On 2014-03-19 23:53, Curtis Maloney wrote:
>
>
> On 20 March 2014 08:58, Florian Demmer <fde...@gmail.com

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
wasn't accessed.

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
https://docs.djangoproject.com/en/dev/ref/utils/

on the other hand i'd like to have safe, clean cache invalidation
without lots of boilerplate every time i need to invalidate a
@cached_property.

... and so i was curious about a patch doing something else, if there
were one already written but just not submitted.


br
Florian