New PEP: Attribute Access Handlers

[Gordon McMillan]

Bjorn Pettersen wrote:
> Gordon McMillan wrote:

> > Of course you don't! Because Paul forgot to tell you that the
> > first proposal said that defining one or more of
> > __set/get/del_XXX__ automatically defines all 3, with default
> > behavior of "you can't do that". So a base class defining
> > __get_X__ and a derived class defining __set_X__ will have the
> > wrong semantics 50% of the time whichever way you choose to
> > handle it.
> 
> Hey, I think I understand it now <wink>!  So the reason you need
> to install _one_ attribute handler with either scheme is that XXX
> has no relation to an actual attribute ("it is disallowed to have
> an attribute named XXX in the same instance dictionary as a
> method named __attr_XXX__.") It's therefore impossible to have a
> default set/get/del handler with the common semantics of
> setting/getting/deleting the attribute. Solving that problem by
> associating XXX with a 'real' attribute can't be done since it
> would probably require new syntax, and wouldn't always be
> desired... Am I close?

Hmmm. Well, the implementation actually puts the access 
handler into class.__dict__ as 'XXX'. So the statement that "it 
is disallowed to have an attribute named XXX in the same 
instance dictionary as a method named __attr_XXX__" is a bit 
disingeneous (I mean besides the fact that methods only get 
into an instance dict when indulging in memory-leaking 
hackery). There *is* an attribute named XXX, and this is the 
basis for "get" access being sped up (getattr sees that the 
thing is an access handler, and reacts accordingly).

However, the statement self.__dict__['XXX'] = 3 will work (there 
actually nothing there to "disallow" it), and further, it will undo 
the hack (it will never get called - for set or del either).

So, if you understood the "semantics" section, you probably 
didn't understand the "proposed implementation" and vice 
versa.  Therefor I can unequivocally answer both "Yes" and 
"No" to your final query <wink>.

- Gordon