On 2014-03-19 23:53, Curtis Maloney wrote:
> 
> 
> On 20 March 2014 08:58, Florian Demmer <fdem...@gmail.com
> <mailto:fdem...@gmail.com>> wrote:
> 
> 
> 
>     On Thursday, August 8, 2013 6:59:14 PM UTC+2, Łukasz Rekucki wrote:
> 
>         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 ?
> 
> 
>     wow, that AttributeError is super annoying to handle... i'd
>     apprechiate a patch for that if you have it already written!
> 
> 
> 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.

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



-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/532AC645.3040800%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to