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