>>>>> "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).
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?
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.
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.
-Barry
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