Property Not Working with Getter and Setter

Why is the property setter is not working properly?

The problem is with the name of the property, class properties and setter function inputs should be different. Also, you should implement a getter.
Working example:

class Person:
def __init__(self, age=20):
self._age = age

def set_age(self, new_age):
print(new_age)
if new_age > 0 and new_age < 120:
self._age = new_age

def get_age(self):
return self._age

age = property(get_age, set_age)

i=Person()
i.age = 21

@property setter not called in python 3

The setter is only invoked when you try to assign to the property. In the line

pozza = pizzo.getCiao('setter')

you first access the value of the property with pizzo.getCiao (which calls the getter and returns the string "getter", then attempts to call the string as a function with the argument 'setter'.

You have basially created a read-only property:

>>> pizzo = DumbClass('getter')
>>> pizzo.getCiao
'getter'
>>> pizzo.getCiao = 'foo'
Traceback (most recent call last):
File "", line 1, in
AttributeError: can't set attribute

This is because you didn't use the same name when defining both the getter and setter, so your property doesn't have a setter. (Arguably, getCiao.setter should probably raise an error right away, since the name matters, but it doesn't. C'est la vie.)

So the right thing to do is use the same name for both. The usual convention is to use an private variable with the "same" name as the property to store the underlying data for simple properties like this.

class DumbClass:
def __init__(self, p):
self._ciao = p

@property
def ciao(self):
return self._ciao

@ciao.setter
def ciao(self, v):
self._ciao = v

Now you should be able to both get and set the value of the propery.

>>> d = DumbClass("hi")
>>> d.ciao
'hi'
>>> d.ciao = 'bye'
>>> d.ciao
'bye'

Getter and Setter not working

Since you're using an auto property, you should be using Account for all references to the property.

If you're looking to use a backing field, then you'll need to have the backing field (account) in the get and set.

Example:

public string Account 
{
get { return account; }
set { account = value; }
}
private string account;

Example of use for the auto property:

public CustSTIOrder(Account ord)
{
Account = ord.Account;
// the rest
}

Using @property versus getters and setters

Prefer properties. It's what they're there for.

The reason is that all attributes are public in Python. Starting names with an underscore or two is just a warning that the given attribute is an implementation detail that may not stay the same in future versions of the code. It doesn't prevent you from actually getting or setting that attribute. Therefore, standard attribute access is the normal, Pythonic way of, well, accessing attributes.

The advantage of properties is that they are syntactically identical to attribute access, so you can change from one to another without any changes to client code. You could even have one version of a class that uses properties (say, for code-by-contract or debugging) and one that doesn't for production, without changing the code that uses it. At the same time, you don't have to write getters and setters for everything just in case you might need to better control access later.

Using getter/setter for property makes it not appear in reflection (mirror)

For the first problem I ended up using the following extension, which does see properties with getters/setters unlike Mirror:

extension NSObject {

func propertiesNames() -> [String] {

var count : UInt32 = 0
let classToInspect = type(of: self)

guard let properties : UnsafeMutablePointer = class_copyPropertyList(classToInspect, &count) else { return [] }

var propertyNames : [String] = []

let intCount = Int(count)

for i in 0..
let property : objc_property_t = properties[i]
let propertyName = NSString(utf8String: property_getName(property))!

propertyNames.append(propertyName as String)
}

free(properties)

return propertyNames
}
}

As for the second issue I ended up copying each property over from the theme to the button as they are always the same. The goal was to avoid having to maintain a Theme class to bridge values every time something new is implemented in ZFButton.



Related Topics



Leave a reply



Submit