Home Original page

"Data" vs. "Non-data" Descriptors in PEP 252, and "once" attributes

Phillip J. Eby pje at telecommunity.com
Mon Feb 25 09:49:59 EST 2002 
In article <j48z9hn8tl.fsf at informatik.hu-berlin.de>, 
loewis at informatik.hu-berlin.de says...
> Phillip J. Eby <pje at telecommunity.com> writes:
> 
> > Interestingly, this does *not* work if you try to do something similar 
> > with the built-in 'property' type.  
> 
> I don't find this surprising. The builtin property type has a fixed
> meaning for its constructor argument: they are callables, and they are
> called on each access. How did you mean to implement your "once"
> properties with it?

By supplying only an 'fget' function, so that the 'property' object would 
be a "non-data" descriptor.  Which doesn't work.  Even if you use a 
function which caches its result in the instance dictionary, the function 
is still called every time, because 'property' instances are always 
"data" descriptors.

In retrospect, I realize that it wouldn't make sense for 'property' 
to create a new type on each call, or use a different type based on which 
functions you supply.  And since the data/non-data determination is made 
via type slots, it's understandable in retrospect that it would not 
change based on the functions passed.

This wasn't really obvious to me at first, however.  On the surface, 
creating a 'property' seemed isomorphic to writing a property class of my 
own with '__get__' and '__set__' methods; I was therefore initially 
puzzled by the behavior difference between writing my own property type, 
and using the built-in one.  Although I was supplying a only a "get" 
method in both cases, the behavior was different, and that was what 
caused me to go PEP-hunting and source-digging to understand the 
difference.


> > Operationally, it seems it would be hard to change any of this in a way 
> > that would break my "once" examples without also breaking lots of other 
> > things.  But the PEP doesn't really give an official way to create either 
> > a data or non-data descriptor; it just says what the current 
> > implementation does.  Hence my concern.
> 
> Nobody can tell the future with certainty. If you think that certain
> wording would tighten the PEP to make you feel more safe, just submit
> a patch for the PEP to SF.

I wasn't aware that one could do that.  Thanks for the tip; I'll look 
into it.  I don't imagine it'll even be a big patch; just an explanation 
that a data descriptor is one which includes a "tp_descr_set" function.  
Or perhaps it would be better to drop the "data/non-data" terms and refer 
to "writable" vs. "read-only" descriptors.
More information about the Python-list mailing list