properties and get/set methods
Mike C. Fletcher
mcfletch at rogers.com
Sun Apr 6 14:17:05 EDT 2003
John Roth wrote:
>"Mike C. Fletcher" <mcfletch at rogers.com> wrote in message
>news:mailman.1049643850.17962.python-list at python.org...
>
>
...
>>When people start using properties heavily, the definition migrates
>>closer to "describing a property/attribute slot of an object" with the
>>access mediation of getter/setters being a side-effect of that
>>description. So after a while, the people using them start seeing
>>
>>
>them
>
>
>>in a different light than those for whom they are still just for
>>wrapping getter/setter methods.
>>
del Mike's continued blathering...
>I agree, that's a better solution although there is one big difficulty.
>The approach works quite well in Java, where you've got the ability
>to declare a variable as "final." You don't have that ability in Python,
>so you run the risk of someone accidentally rebinding the field rather
>than
>using the extra level of indirection needed to access it correctly.
>
I haven't had a problem with needing final yet. I can certainly imagine
cases where it would cause a problem, but I'm one of those old-style
Python programmers. I figure if you're sub-classing a class you better
know what it's fields are before you start sub-classing. You could do
something about it by defining properties on your meta-classes, but as I
say, I haven't felt the need to do it yet.
>Following on to this idea, would you say that the property syntax
>introduced in Python 2.2 was a mistake? It should have been more
>general?
>
Fixes I can easily imagine being useful:
* add a parameter to get/set/del methods telling them which
attribute name is being used to access them
o possibly do this as another hook level to leave current code
as-is, but it really does seem like something to which the
methods should have access
* provide C-level (i.e. fast) standard get/set/del implementation
functions that support both __dict__ and __slots__ based objects
for use when you just want to say "do what you'd normally do"
(i.e. when you only want to override set and del, not get (which
is normally far more common and speed-sensitive))
I'm not, however, saying the 2.2 properties were a mistake. If I recall
correctly, they were introduced as a "provide something now, worry about
details (such as potentially a syntactic wrapper) later" feature.
They're a very useful feature even with a few little warts, and I'd much
rather have them as-is than not have them (which would likely have been
the other option). The API could have been slightly more general, true,
but oh well.
Enjoy,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
More information about the Python-list
mailing list