[Python-ideas] The Descriptor Protocol...

[Martin Chilvers]

Hi Raymond,

On 02/03/2011 16:10, Raymond Hettinger wrote:
> I've gotten this question a couple times. There usual answers are:
>
> * Why? Because Guido implemented it that way ;-)
>
> * Why did he pick a signature that dropped the "key"? Mostly likely, it
> is because none of the use-cases he had in mind required it. The keyless
> API suffices to implement property(), super(), classmethod(),
> staticmethod(), bound method, __slots__, various features of new-style
> classes, and a reimplementation old-style classes.

Probably so, but it still smells in terms of the information flow 
through the various levels of the API :^)

> Yes, option b is the usual way to do it (there are a number of recipes
> that use this approach).
>
> For the most part, that shouldn't be an unfamiliar pattern to Python
> developers. For example, named tuples repeat the name:
> Point = namedtuple('Point', ('x', 'y')).
>
> Sometimes the language provides syntax to do the work for us, like
> "class A: ..." instead of "A = type('A', (), {})", but for other
> situations, it isn't unusual to pass in a name as a string literal so
> that an object will know its own name.
>
> For Python 4, perhaps you can convince Guido to add a key argument to
> the signature for __get__ and __set__. It would make a handful of
> recipes a bit prettier at the expense of being a total waste for all the
> other use cases that don't need it.

Just because some use cases don't use it doesn't mean it is a total 
waste ;^) The current design mean that descriptors can't be (sensibly) 
shared across differently named attributes which has major implications 
for scaleability...

> I think everyone who writes a descriptor that needs the "key" will chafe
> at the current design. It bugged me at first, but the workaround is easy
> and after a while it doesn't seem as bothersome.

Yep - workarounds generally are easy, but if the workarounds appear 
often enough its usually a symptom that the underlying code might be 
improved...

Martin