Tkinter跨Widget调用方法：实例创建顺序触发AttributeError的原理与实践

你的判断完全正确。Python的实例属性是运行时赋值才会绑定到实例对象上的，不存在类定义完成后就自动把所有类里写的self.xxx属性挂到实例上的逻辑。
逐行拆解原代码的执行时序：

1. 进入parent_class的__init__方法，此时正在构造的实例已经完成了Frame基类初始化、调用了self.grid()，实例的属性字典里暂时没有first、second两个属性。
2. 执行到self.second = child_two(self)，把当前处于初始化中途的parent_class实例作为parent参数传入child_two的构造函数。
3. 进入child_two的构造函数，在创建Button控件时，command参数的表达式parent.first.print_x会被立刻求值——Tkinter的控件构造逻辑会在创建时就拿到command对应的可调用对象引用，不是等到按钮被点击时才解析。
4. 此时去取parent.first属性，但parent对应的parent_class实例还没走到给self.first赋值的代码行，属性字典里根本不存在first键，因此抛出AttributeError。
   反转创建顺序后不报错的逻辑也很好理解：先执行self.first = child_one(self)，把first属性绑定到实例上，再创建child_two时，parent.first已经是存在的合法属性，自然可以正常拿到对应的方法引用。

• 报错和创建的是第几个parent_class实例没有任何关系：只要__init__里的属性赋值顺序没有变，每一个新创建的parent_class实例都会在初始化时触发同样的报错。因为每个实例的属性都是独立绑定的，和其他实例的状态完全无关。
• 这个问题完全不是Tkinter特有的，是Python面向对象编程的通用时序问题。你之前没法用通用类复现，是因为大部分普通类的构造函数不会在初始化时就立刻求值传入的可调用对象参数——只要构造函数里需要立即解析依赖的实例属性，用普通类完全可以复现完全相同的报错，比如下面的通用类示例：

class A:
    def method(self):
        print("测试方法")

class B:
    def __init__(self, parent, callback):
        # 构造时立刻拿到callback的引用，和Tkinter Button的逻辑一致
        self.cb = callback

class P:
    def __init__(self):
        # 先创建B，此时需要立刻解析self.a.method
        self.b = B(self, self.a.method)
        self.a = A()

if __name__ == '__main__':
    P()

运行这段代码会抛出和原Tkinter代码完全一样的AttributeError: 'P' object has no attribute 'a'，全程没有任何Tkinter依赖。

首先直接回答：把print_x改成parent_class的静态方法不能直接解决当前的报错。因为当前的print_x是child_one的实例方法，需要访问child_one自己的x属性，就算把方法移到parent_class上做成静态方法，既拿不到child_one的实例状态，也解决不了“构造child_two时parent.first属性还不存在”的时序问题。

针对这类组件交互的场景，有几个经过验证的优化方向，按改动量从小到大排序：

1. 延迟求值时机，简单适配现有代码
   把控件创建时立刻解析属性的逻辑，改成lambda包裹的延迟求值，让属性解析的时机从“构造控件时”推迟到“按钮被点击时”。这时候整个程序已经进入mainloop，所有组件都已经完成初始化，不管组件创建顺序如何都不会触发时序报错：

   # child_two内部的Button创建代码
   self.b = ttk.Button(
       self, 
       text='Button 1',
       # 用lambda延迟，点击时才会解析parent.first.print_x
       command=lambda: parent.first.print_x
   ).grid()
   

2. 解耦组件依赖，不要硬编码跨组件访问路径
   现有代码里child_two直接硬编码访问parent.first的写法，属于典型的紧耦合：子组件完全依赖父组件的内部结构，只要父组件的属性名、创建顺序变了，子组件就会失效。
   更合理的写法是让父组件显式给子组件传需要的回调，而不是让子组件自己去父实例上找属性：
   • 修改child_two的构造函数，接收外部传入的按钮点击回调，不要内部硬编码找父级的子组件
   • 父组件在创建子组件时，直接把需要触发的逻辑作为回调传入
     这样就算后续修改组件结构，只要回调的传参逻辑不变，子组件不需要任何调整。
3. 状态归属调整时再考虑静态/类方法
   静态/类方法的适用场景是“不依赖特定实例状态、通用的逻辑”，如果后续你把x的状态从child_one移到parent_class上，对应的print_x逻辑完全可以移到parent_class上做成普通实例方法，甚至不需要做成静态方法。但这属于业务逻辑结构调整，不是为了解决时序报错的通用方案。

内容的提问来源于stack exchange，提问作者BloodBuzz Corio