"M.-A. Lemburg" wrote:
>
> ..
>
> I don't get the point: how is this better than defining
> explicit access methods ?
>
> get_foo(self)
> set_foo(self, value)
> del_foo(self)
It's more verbose for the client programmer and it forces them to "know"
that there is magical processing going on under the covers. I'm going to
provide examples of where we do or would use a feature like this in
extension modules so that you can see that I'm just trying to extend the
fun to Python programmers (not just extension writers).
There are about a million places in Python's implementation where
extension modules do computation like:
def __setattr__( name, val ):
if attribute_to_set=="__class__":
assert PyClass_Check( val ):
elif attribute_to_set=="__dict__":
assert PyDict_Check( val ):
One could imagine a circumstance in which we decide to "trap"
sys.stdin=o so that if it HASN'T been set we could use a more efficient
stdout writing protocol internal to the interpreter implementation.
In general, it is useful when you want to migrate from an
attribute-setting situation to a computational situation without
changing existing code.
You can also think of the various places where the interpreter traps
when you try to write to a read-only attribute.
In pyexpat, when you assign to certain variables we "push" that
information down to expat itself (set variables in expat).
Imagine trying to read or write an attribute over COM or CORBA. Why
should Python programmers have to use foo.set("a", 5) when VB
programmers just say foo.a=5? Mark Hammond currently does this with
__getattr__ I believe. It would be more efficient better to
auto-generate getter and setter methods.
In general, its useful for proxy situations where the set of attribute
you want to proxy are known in advance.
It's just a cleaner, Pythonic way to do something that is already common
either using __getattr__ hacks or in extension modules.
> These not only define a distinct interface, but also provide
> more flexibility, e.g. get_foo() could have a default argument.
I'm not taking away anyone's right to use methods. The logical extension
of your argument is that we should always use getter/setter methods in
case we need to add arguments to them later. That's the Java stance but
I think we can differentiate ourselves from Java with clearer code.
--
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