Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) wrote,
> Paul, this is clearly unclear <0.1 wink>. I for one don't get it.
> The whole point of __getattr__, __setattr__ is to trap attribute
> accesses and assignment. Python lets you trap the attribute binding
> process through these two functions. At yes, it is common case,
> because people want to specialize the binding rules in an object's
> namespace.
The __getattr__ and __setattr__ mechanism is useful but hard to use.
Paul's proposal suggests makeing it easier to override access for a
single attribute.... or am I unclear on what you are unclear about?
> However, this is defined only for Python's instance objects. If this
> is intended to generalize the concept for builtin objects, then you
> reach the object model deficiencies (metacalass, type dochotomy, etc.)
> which is not a trivial problem.
Whoa.... where did that come from. While the idea behind Paul's
proposal could easily be applied to builtin objects (I've been using
the technique for years) he's not even mentioning them in the
proposal. It would still be up to the extension writer to decide how
best to implement tp_setattr and tp_getattr. Only the
instanceobject's tp_setattr and tp_getattr would need to change.
> If you're running after performance, because this programmable
> trapping occurs only in Python, well, state it explicitely in your
> writing.
I dont see performance as the big issue here. What I do see is a
tidying up of a common usage of the current __setattr__/__getattr__
mechanism. For better or worse, it will make it much easier to write
code which controls access to an attribute.
> I believe that you're running after the generalization. I am not
> sure that what's in this per-PEP is a generic solution
> though. Because you're discussing handlers written in Pythonland
> (and this is also unclear in your writing). Simply put, these
> handlers would be invoked by hooks taken into account by the C
> code. Except hooking dict lookups with Python or C handlers, I don't
> see the point of this PEP.
Wow! What does Paul's proposal have to do with hooking dict lookups?
...or is that what you are wondering? If that's what you are
wondering, wonder no more. There is no connection.
> If the handlers are written in Python, this is what you get with
> __getattr__ and __setattr__. If you think C handlers, well, tell us
> about it explicitely.
Ah... now I see where *you* think Paul is going.
To implement this, I would write up a little object called attrobject
which would be very similar to a instancemethod. When the class is
created I would check for methods whos names matched the __attr__XXX
pattern. For each of these methods I would create an attrobject to
wrap it then stick that back in the class dictionary under the name
XXX. The tp_getattr method would then go through it's normal lookup
procedure. But, before returning the result it would check the type
of the object. If the object is an attrobject, the associated method
would be called. The result of that call would be return from
tp_getattr.
The tp_setattr changes are where Paul's proposal loses. To make this
work it becomes necessary to first attempt a "modified" getattr to
determine if an attrobject exist for this attribute. I say "modified"
getattr because in this case we dont really want to evaluate the
attrobject. If no attrobject exists for the named attribute the set
operation proceed as usual. If one does exist, it's associated method
is called with the specified value. What hurts here is that it is now
necessary to do that "modified" getattr on each set operation.
If this is what you mean by "C handlers", then that's what Paul (in my
opinion) is saying. Otherwise...
--
Donald Beaudry Ab Initio Software Corp.
201 Spring Street
donb@init.com Lexington, MA 02421
...Will hack for sushi...
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