PEP: ???
Title: Computed Attributes
Version: $Revision: 1.0 $
Owner: paul@prescod.net
Python-Version: 2.0
Status: Incomplete
Introduction
This PEP describes a feature to make it easier to use Python
attribute set/get/del syntax to fetch the results of a computation
or to invoke computation. This feature has been emulated using
__getattr__/__setattr__/__delattr__ but this approach suffers
severe usability and performance concerns.
Syntax
Special methods should declare themselves with declarations of the
following form:
class x:
def __get_foo__(self ): ... def __set_foo__(self, value ): ...
def __del_foo__(self ): ...
They are used like this:
fooval=x.foo
x.foo=fooval+5
del x.foo
Semantics
References of the sort x.y should be taken, if x is an instance type
of a class with a __get_y__ method as being equivalent to a call to
that method. Code that assigns to y should instead call __set_y__
if that method is defined on x's class. Code that deletes x.y should
call __del_y__ if that method is defined on x's class.
It is disallowed to actually have an attribute named y in the
dictionary for reasons that will become clear when we discuss the
implementation.
It is not required that every special method have two more matching
special methods. If one is declared then the other two operations
are
effectively prohibited and will raise an exception. This is an easy
way to make read-only (or even write-only or delete-only)
attributes.
An implementation of __get_y__ takes precedence over an
implementation of __getattr__ based on the principle that
__getattr__ is supposed to be invoked only after finding an
appropriate attribute has failed. This is important for
acceptable performance.
An implementation of __set_y__ takes precedence over an
implementation of __setattr__ in order to be consistent. The
opposite choice seems fairly feasible also, however. The same
goes for __del_y__.
Proposed Implementation
There is a new object called a computed attribute object. It has
three attributes: get, set, delete. In PyClass_New, methods of
the appropriate form will be detected and converted into objects
(just like unbound method objects). Matching methods go in the same
computed attribute object and missing methods are replaced with a
stub that throws the TypeError. If there are any computed attributes
at all, a flag is set. Let's call it "I_have_computed_attributes"
for now.
A get proceeds as usual until just before the object is returned.
In addition to the current check whether the returned object is a
method it would also check whether a returned object is a computed
attribute. If so, it would invoke the getter method and return
the value. To remove a computed attribute object you could directly
fiddle with the dictionary.
A set proceeds by checking the "I_have_computed_attributes" flag. If
it is not set, everything proceeds as it does today. If it is set
then we must do a dictionary get on the requested object name. If it
returns a computed method attribute then we call the setter function
with the value. If it returns any other object then we discard the
result and continue as we do today.
The I_have_computed_attributes flag is intended to eliminate the
performance degradation of an extra "get" per "set" for objects not
using this feature. You might note that I have not proposed any
logic
to keep this flag up to date as attributes are added and removed
from the instance's dictionary. This is consistent with current
Python. If you add a __setattr__ method to an object after it is in
use, that method will not behave as it would if it were available at
"compile" time.
The implementation of delete is analogous to the implementation
of set.
--
Paul Prescod - Not encumbered by corporate consensus
"Hardly anything more unwelcome can befall a scientific writer than
having the foundations of his edifice shaken after the work is
finished. I have been placed in this position by a letter from
Mr. Bertrand Russell..."
- Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox)
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