"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/
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