【问题标题】:Correct usage of a getter/setter for dictionaries in classes -- prevent the getter to be called when setting an element of the dictionary正确使用类中字典的 getter/setter —— 防止在设置字典元素时调用 getter
【发布时间】:2019-09-22 10:40:09
【问题描述】:

当我通过属性装饰器在类中设置字典元素时,将调用@property getter。当我希望 getter 对输出做一些事情时,这是一个问题。

背景

主题与化学项目有关。

我想编写一个更易读、更易于访问的代码,而不是使用索引等。 new = self.species['CO2'] * fraction 优于 self.species[14] * fraction

我也试过 Correct usage of a getter/setter for dictionary values 但它不能解决setter/getter问题。

目前我通过禁用 getter、定义 get_dict 函数并只允许设置整个字典来解决此问题。

但使用这种方法,我不能简单地通过数组循环(dictA:dictnew_values:numpy array):

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

运行示例

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

支持代码


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

结果

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)

输出

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}

想要的输出

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}

问题

从输出中可以看出,调用的是“Getter”而不是“Setter”。

【问题讨论】:

  • 您可以创建dict 的子类并将所有验证逻辑委托给它的__setitem__。我认为这将是一个更好的设计,而不是试图在 using 类中塞满所有逻辑
  • 我试过这个,如链接中所见,但在它进入新 dict 定义的__setitem__ 之前(使用示例时)它无论如何都会通过getter --> 那是我的问题,我无法正常化它。所以通过NewDict + __setitem__ 方法,它仍然会通过getter——这很糟糕。
  • 为什么不希望输出中的前两行是SetterGetter?示例中的第二行 (test.propA = {'A':5,'B':4,'C':1}) 调用Setter 并打印Setter,第三行 (print(test.propA)) 调用Getter 打印Getter
  • 你说得对,我错过了这个。我加了。

标签: python python-3.x decorator


【解决方案1】:

这里没有任何问题,你得到的输出非常有意义。

您在实际输出中看到了这一点:

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

由于您的示例中的这些行:

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

您对“setter 调用 getter”的观察是错误的,但我明白它的出处。

test.propA 将调用examplepropA getter。不是因为“setter 调用 getter”(坦率地说,setter 甚至没有被这 3 行调用),而是因为 test.propA 需要获取底层字典才能调用它的__setitem__ 方法。

这里唯一的“真正”解决方案是我在 cmets 中建议的更好的设计。您可以example 中编写一个包装器方法,将项目直接设置在_propA 上,但这就像跳过栅栏而不是穿过前门。

【讨论】:

  • 但是如何解决它。如何test.propA+键调用setter。这将使生活变得更加轻松。我将其称为 cantera 问题(化学求解器),您必须摆弄索引而不是使用字符串名称。
  • @pDashman 如果没有更好的设计,您将无法真正解决它。 test.propA总是调用 getter。您可以创建一个包装方法,将项目直接设置在_propA 上,但这就像跳过栅栏而不是穿过大门
  • 因此您的建议是将 setter/getter 功能移至 _propA 定义。所以,应该有一个例程可以看出propApropA['A']之间的区别。
  • 如果@property 装饰器可以判断您是通过= 符号声明某些内容,或者您​​只是想grep 内容,那么将来会很棒。我想在使用任何列表/数组时都会出现同样的问题,比如propA[0]
  • 我尝试过用于数组。这是相同的行为。所以 @property 装饰器实际上只适用于单个输入 (int,float,str) 我猜。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-03-21
  • 2011-06-13
  • 2023-03-07
  • 2019-11-26
相关资源
最近更新 更多