Paul Prescod wrote:
>
> I don't have a PEP number for this yet but I wanted to go through
> another round of comments after changing the mechanism according to Don
> Beaudry's suggestions.
>
> The name has been changed because every attribute is computed at some
> point or another. The important thing is that we are defining methods
> that trap sets/gets to attributes.
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.
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.
If you're running after performance, because this programmable trapping
occurs only in Python, well, state it explicitely in your writing.
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.
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.
or-I-am-missing-the-point-completely y'rs
--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
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