[Python-Dev] PEP 231, __findattr__()

[M.-A. Lemburg]

"Barry A. Warsaw" wrote:
> 
> >>>>> "M" == M  <mal@lemburg.com> writes:
> 
>     M> The PEP does define when and how __findattr__() is called,
>     M> but makes no statement about what it should do or return...
> 
> Good point.  I've clarified that in the PEP.
> 
>     M> Here's a slightly different idea:
> 
>     M> Given the name, I would expect it to go look for an attribute
>     M> and then return the attribute and its container (this doesn't
>     M> seem to be what you have in mind here, though).
> 
> No, because some applications won't need a wrapped object.  E.g. in
> the Java bean example, it just returns the attribute (which is stored
> with a slightly different name).

I was thinking of a standardised helper which could then be
used for all kinds of attribute retrieval techniques. Acquisition
would be easy to do, access control too. In most cases __findattr__
would simply return (self, self.attrname).
 
>     M> An alternative approach given the semantics above would then be
>     M> to first try a __getattr__() lookup and revert to
>     M> __findattr__() in case this fails.
> 
> I don't think this is as useful.  What would that buy you that you
> can't already do today?

Forget that idea... *always* calling __findattr__ is the more
useful way, just like you intended.
 
> The key concept here is that you want to give the class first crack to
> interpose on every attribute access.  You want this hook to get called
> before anybody else can get at, or set, your attributes.  That gives
> you (the class) total control to implement whatever policy is useful.

Right.
 
>     M> I don't think there is any need to overload __setattr__() in
>     M> such a way, because you cannot be sure which object actually
>     M> gets the new attribute.
> 
>     M> By exposing the functionality using a new builtin, findattr(),
>     M> this could be used for all the examples you give too.
> 
> No, because then people couldn't use the object in the normal
> dot-notational way.

Uhm, why not ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/