Michael Foord wrote: >> Note that the behaviour here is still different from that of a data >> descriptor: with a data descriptor, once it gets shadowed in the >> instance dictionary, the descriptor is ignored *completely*. The only >> way to get the descriptor involved again is to eliminate the shadowing. >> The non-data descriptor with only __set__ is just choosing not to >> override the attribute lookup process. >> >> > > Does that mean we need a third class of descriptors that are neither > data descriptors nor non-data descriptors? Not really - leaving out __get__ when defining __set__ just creates a data descriptor that happens to use the default attribute look-up process rather than defining a different one. (Note that I had the data/non-data terminology backwards in my previous message - I tend to think of the two kinds of descriptor as enforced and non-enforced respectively precisely because I have to think about it to remember that "functions are non-data descriptors and properties are data descriptors, hence non-data descriptors only define __get__ while data descriptors define __set__". I don't find the data/non-data terminology intuitive at all) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4