Python property's

Coding
1

This should work in maya 2009 no…

class C(object):
def init(self):
self._x = None

@property
def x(self):
    """I'm the 'x' property."""
    return self._x

@x.setter
def x(self, value):
    self._x = value

Error: ‘property’ object has no attribute ‘setter’

Traceback (most recent call last):

File “<maya console>”, line 1, in <module>

File “<maya console>”, line 10, in C

AttributeError: ‘property’ object has no attribute ‘setter’

doh…
Changed in version 2.6: The getter, setter, and deleter attributes were added.

2

I wasn’t aware of that syntax… I’m quite glad its gone though - thats kinda horrible.

But you can do the same like this:

class SomeKlass(object):
    def getX( self ):
        return self._x
    def setX( self, x ):
        self._x = x
    x = property( getX, setX )

To me this is nicer because the getter and setter methods are available without requiring the user to use properties.

Having said that, I try to avoid properties where possible because it makes it unclear to the consumer of your code that a process is happening.

Plus its really hard to re-factor if for example, you find you no longer need the x property. Doing a grep for “.x” is going to return a few results, probably few of them being relevant. :wink:

3

The property stuff only went in at 2.6, before this you’d use what Hamish said to bind the properties prior to that. I have to say mind you we do tend to use get and setter functions instead. The main reason is that if you’ve got simple properties like self.FarmeRate , then you need to have an instance of the object to retrieve the property, and half the time you don’t actually want to. Or certainly not on generic modules.

Yes we do ues properties, but only really where it makes sense.

4

This coming from a .NET fan: use get/set methods instead of properties.

5

Hey good post… but could you please elaborate it?

6

I think properties have their place, especially where you’re just wanting to use a class as a data container as opposed to one with significant behaviors attached – i.e. like with a simple struct in C. It kind of appeals to me to expose ordinary data as data, i.e. using objectRef.propname syntax from the outside, but while still being able to impose some input data validity control for write access.

It’s really just syntactic sugar in the end though. Since the designers of the language didn’t see fit to provide the means to formally declare data and functions as public or private, you kind of have to roll your own access protection scheme (and don’t you guys just love the single and double-leading-underscore thing :confused: ). Since most of my plans revolve around Maya, I’ll just go with the flow stylistically with PyMel and the new Maya Python API. Providing a consistent interface in the end is probably the best path.