1

When I set an element of a dictionary in a class via property decorator, the @property getter will be called. This is a problem when I want the getter to do something to the output.

Background

The topic is related to a chemistry project.

I want to make a more readable and more accessible code, instead of working with indexes, eq. new = self.species['CO2'] * fraction is better then self.species[14] * fraction

I also tried Correct usage of a getter/setter for dictionary values but it can not solve the setter/getter problem.

Currently I go around this issue by dissabling the getter, defining a get_dict function and only allow the whole dictionary to be set.

But with this approach I can not simply loop via arrays (dictA:dict and new_values:numpy array):

for i,value in enumerate(dictA):
    dictA[value] = new_values[i]

Running Example

class example():

    def __init__(self):
        self._propA = {'A':1,'B':0,'C':0}

    @property
    def propA(self):
        print('Getter')
        return normalize_dict(self._propA)

    @propA.setter
    def propA(self,propB:dict):
        print('Setter')
        match = list(set(propB).difference(self._propA))
        if match:
            raise ValueError('{match} is/are not part of the required input: {listing}'.format(match=match,listing=list(self._propA.keys())))
        else:
            for i,value in enumerate(propB):
                self._propA[value] = propB[value]

        return self._propA

Supporting code


def normalize_dict(inquiry: dict):

    inquiry_new = {}

    try:
        for i,value in enumerate(dict(inquiry)):
            inquiry_new[value] = inquiry[value]
    except TypeError:
        error_string = 'Not a dictionary type class!'
        raise TypeError(error_string)


    for i,(valA,valB) in enumerate(inquiry_new.items()):
        if type(valB)!=float and type(valB)!=int:
            raise ValueError(valB,'is not a number')
        if float(valB) < 0:
            print ('Input is negative. They are ignored!')
            continue

    sum = 0
    for i,(valA,valB) in enumerate(inquiry_new.items()):
        if valB < 0:
            valB = 0
        sum += valB

    for i,(valA,valB) in enumerate(inquiry_new.items()):
        inquiry_new[valA] = valB/sum

    return inquiry_new

Results

main.py:


test = example()
test.propA = {'A':5,'B':4,'C':1}
print(test.propA)
test.propA = { 'A':1 }
test.propA = { 'B':5 }
test.propA = { 'C':4 }
print(test.propA)
test.propA['A'] = 5
test.propA['B'] = 4
test.propA['C'] = 1
print(test.propA)

Output

Setter
Getter
{'A': 0.5, 'B': 0.4, 'C': 0.1}
Setter
Setter
Setter
Getter
{'A': 0.1, 'B': 0.5, 'C': 0.4}
Getter
Getter
Getter
Getter
{'A': 0.1, 'B': 0.5, 'C': 0.4}

Wanted Output

Setter
Getter
{'A': 0.5, 'B': 0.4, 'C': 0.1}
Setter
Setter
Setter
Getter
{'A': 0.1, 'B': 0.5, 'C': 0.4}
Setter
Setter
Setter
Getter
{'A': 0.5, 'B': 0.4, 'C': 0.1}

Issues

As you can see from the output the 'Getter' is called instead of the 'Setter'.

maro12
  • 109
  • 7
  • You can create a subclass of `dict` and delegate all the verification logic to its `__setitem__`. I think that would be a much better design rather than trying to cram all the logic in the using class – DeepSpace Sep 22 '19 at 10:48
  • I tried this one, as seen in the link, BUT before it goes to the `__setitem__` of the new dict definition (when using the example) it will go through the getter anyway --> that's my problem, I can not normalize it properly. So via the `NewDict` + `__setitem__` method it still goes through the getter -- this is bad. – maro12 Sep 22 '19 at 10:52
  • 1
    Why would you not expect the first 2 lines in the output to be `Setter` and `Getter`? The second line in the example (`test.propA = {'A':5,'B':4,'C':1}`) calls the `Setter` and that prints `Setter`, and the third line (`print(test.propA)`) calls the `Getter` that prints `Getter` – DeepSpace Sep 22 '19 at 11:00
  • Your are right I missed this. I added it. – maro12 Sep 22 '19 at 11:08

1 Answers1

0

There isn't any issue here, the output you get makes perfect sense.

You are seeing this in your actual output:

Getter
Getter
Getter
Getter
{'A': 0.5, 'B': 0.4, 'C': 0.1}

Due to these lines in your example:

test.propA['A'] = 5
test.propA['B'] = 4
test.propA['C'] = 1
print(test.propA)

Your observation that "the setter calls the getter" is wrong, but I understand where it comes from.

test.propA will call example's propA getter. Not because "the setter calls the getter" (to be frank, the setter is not even being called by these 3 lines), but simply because test.propA needs to get the underlying dictionary before it can call its __setitem__ method.

The only "real" solution here would be a better design like I suggested in the comments. You could write a wrapper method in example that would set the items directly on _propA but that would be like jumping over the fence instead of walking through the front gate.

DeepSpace
  • 78,697
  • 11
  • 109
  • 154
  • But how to solve it. How to `test.propA` + key calls the setter. This would make life so much easier. I call this the __cantera__ problem (a chemistry solver) where you have to fiddle around with indexes instead just use the string name. – maro12 Sep 22 '19 at 11:16
  • @pDashman You can't really solve it without a better design. `test.propA` will **always** call the getter. You *could* create a wrapper method that will set the items directly on `_propA` but that's like jumping over the fence instead of walking through the gate – DeepSpace Sep 22 '19 at 11:21
  • So your suggestion is be to move the setter/getter functionality to the `_propA` definitions. So, there should be a routine which can see the difference between `propA` and `propA['A']`. – maro12 Sep 22 '19 at 11:29
  • Would be great in the future if the `@property` decorator could tell if you declare something via `=` sign or if you just want to grep the content. I guess the same problem will accure when using any list/arrays, like `propA[0]`. – maro12 Sep 22 '19 at 11:37
  • I tried it for arrays. It is the same behavior. So `@property` decorator is actually only good for single input (int,float,str) I guess. – maro12 Sep 22 '19 at 11:56