Python重载__add__采用不同返回类型实现infoo与foo交互是否合规？

你这套"单元素和容器做加法自动返回容器实例"的核心设计思路，本身是符合Python运算符重载的通用惯例的——类似numpy、pandas这类广泛使用的库，都采用了标量运算自动返回对应容器、容器运算保持返回容器类型的设计逻辑，用户使用时不需要手动做类型转换，体验是流畅的。但当前的具体实现存在多个违反Python编码约定、容易引发逻辑bug的问题，还达不到良好实践的标准。

现有实现的核心缺陷 #

• 冗余且有隐患的类型判断逻辑
  你通过infoo_type = type(infoo())的方式获取类对象做类型判断，属于完全没必要的写法。Python的isinstance判断直接传入类对象本身即可，不需要实例化后再取类型。这种写法后续如果给infoo类增加必填的初始化参数，这行代码会直接触发实例化报错，引入无意义的耦合。
• 加法逻辑的不对称漏洞
  Python解释器处理a + b时，会优先调用a的__add__方法，如果方法返回NotImplemented，才会去尝试调用b的__radd__反向方法。当前实现只覆盖了两个方向的部分场景：
  • foo实例加infoo实例、foo实例加foo实例，逻辑可正常运行
  • infoo实例加infoo实例，逻辑可正常运行
    但完全没有覆盖剩余的反向场景：
  • 当用户执行infoo实例 + foo实例时，infoo.__add__方法不会校验右操作数的类型，会直接把整个foo实例当成单个元素塞进新的infoo列表，导致列表里混入非infoo类型的对象
  • 当用户执行其他自定义类型对象加foo/infoo实例时，因为没有实现__radd__方法，会直接抛出未捕获的TypeError
    这种不对称的逻辑会给用户带来极强的认知负担，没人能提前预判交换两个操作数的顺序会得到什么类型的返回值。
• 缺失的类型安全校验
  拼接元素列表时没有做严格的类型校验，哪怕传入的操作数是字符串、数字或者其他无关节点，代码也不会抛出明确的错误，会直接把无关节点存入args列表，等后续业务逻辑运行到具体处理元素的步骤时才会触发报错，排查成本极高。
• 破坏封装性的公开内部属性
  你把存储元素的self.args直接设为公开属性，外部代码可以完全绕过类的校验逻辑随意修改内部存储的列表内容，完全破坏了容器类的封装边界。

符合Python惯例的改进方向 #

• 删掉冗余的infoo_type定义，类型判断直接使用isinstance(other, infoo)的标准写法，降低无意义的耦合。
• 补全反向运算符方法的逻辑：
  • 给foo类增加__radd__方法，直接复用__add__的逻辑，可简化写为__radd__ = __add__
  • 修改infoo.__add__的判断逻辑：当右操作数是foo类型时，直接把右操作数的内部元素列表和当前infoo实例拼接，返回新的foo实例，绝不把foo对象本身当成元素存入列表
• 统一类型校验规则：所有存入args列表的元素都要确保是infoo的实例，遇到不匹配的类型直接抛出带明确提示的TypeError，不要把校验逻辑留到后续业务环节。
• 将内部存储的列表改为私有属性（命名为self._args），对外只提供只读的访问接口，禁止外部随意修改内部存储的元素集合。

参考Python标准库的容器类设计约定，所有同类型容器的运算逻辑都要保持元素类型统一，不会出现容器本身被作为元素嵌套进同类型容器的情况，这也是你当前实现需要重点规避的设计坑点。

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