"Data" vs. "Non-data" Descriptors in PEP 252, and "once" attributes
Phillip J. Eby
pje at telecommunity.com
Mon Feb 25 15:49:59 CET 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
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
> > 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