当前位置: 首页 > 面试题库 >

这个Python模式是否有任何“陷阱”?

东门晟
2023-03-14
问题内容

这是我正在考虑使用的模式:

class Dicty(dict): 
    def __init__(self): 
         self.__dict__ = self

d = Dicty()
d.foo = 'bar' 
print d['foo']
>>> bar 
d['foo'] = 'baz'
print d.foo
>>> 'baz'

通常,相对于dict get / set访问,我更喜欢对象属性访问的语义,但是在某些情况下,需要像dict一样的访问(例如d['foo-bar'] = 'baz'),并且在这些情况下,我不希望使用特殊的gettersetter方法,因此,具有共享属性的dict和object同时具有双重行为。

是否有上述模式的陷阱?


问题答案:

这是达到相同效果的一种不太“ hacky”的方法:

class Dicty(dict):
    def __getattr__(self, key):
        return self[key]

    def __setattr__(self, key, value):
        self[key] = value

认为
您的方法也可以正常工作,但是__dict__像这样设置属性似乎在样式上有点困难,并且如果其他人最终还是会阅读您的代码,则势必会引起一些问题。



 类似资料:
  • 当从@RestController而不是DTO返回@Entity时,是否存在任何缺陷?这样地:

  • 问题内容: 我们已经获得了在Python 2.6下运行的代码库。为了准备Python 3.0,我们开始添加: 进入我们的文件(我们对其进行修改)。我想知道是否还有其他人正在这样做并且遇到了任何非显而易见的陷阱(也许在花费大量时间进行调试之后)。 问题答案: 我处理unicode字符串的主要问题来源是将utf-8编码的字符串与unicode的字符串混合使用。 例如,考虑以下脚本。 py 一个 运行的

  • 问题内容: 我在运行于MS SQL Server 2005之上的.NET 2.0 Web应用程序上遇到了非常少见却令人讨厌的SQL死锁。过去,我们一直以非常经验的方式处理SQL死锁-基本上调整查询直到工作。 但是,我发现这种方法非常不令人满意:既耗时又不可靠。我非常希望遵循确定性查询模式,该模式将通过设计确保永远不会遇到SQL死锁。 例如,在C#多线程编程中,必须按照其字典顺序采用简单的设计规则(

  • 假设我有两个线程像这样运行: 在更新共享图像的像素时执行计算的线程 线程B定期读取图像并将其复制到屏幕上 线程A执行工作速度很快,比如每秒100万更新,所以我怀疑经常锁定/互斥锁/监视器是个坏主意。但是如果没有锁,也没有办法从线程A到线程B建立一个发生前关系,那么通过Java内存模型(JMM规范)线程B根本不能保证看到线程A对映像的任何更新... 所以我认为,最起码的解决方案是线程A和线程B都在同

  • 这个问题在我的项目中经常出现。作为一个例子,假设我有两个接口,一个从API检索信息,另一个解析这些信息。 现在,我可能需要有不同的API,因此我将有许多的实现,但每个实现都需要自己的。 这看起来与Bridge设计模式所建议的非常相似,但是该模式允许任何APIClient使用任何APIParser(我说的对吗?) 那么,有没有更好的解决方案呢?或者也许这很好,不需要重构它。 另外,也许parse不是

  • 问题内容: 我在项目中使用JUnit4和Hibernate3。Hibernate依赖于Slf4j,因此我的项目也包括此库。现在,我想在单元测试中使用Slf4j,以便记录补充测试信息。您能否提供一个简短的示例,说明我的单元测试仅记录一行文本的外观?最好在多个测试中 不重复代码 。 问题答案: 我还喜欢在我的DAO类的JUnit测试中使用slf4j。当您创建新测试或修改旧测试时,它确实有帮助。我通常将