逐步重定义类触发Pylint R0903错误的处理及类风格差异咨询

你提到的增量类定义代码如下：

class MySuperClass():
    pass


class MySuperClass(MySuperClass):
    def method_one(self, x):
        (do something)


class MySuperClass(MySuperClass):
    def method_two(self, y):
        (do something else)

1. 是否需要修复Pylint的R0903报错 #

该报错属于Pylint的代码风格校验规则，本身不影响代码的正常运行，你可以根据使用场景决定处理方式：

• 如果代码仅用于个人临时测试，无需其他人维护，可以保留原有写法，在对应报错行添加注释# pylint: disable=too-few-public-methods即可屏蔽告警。
• 如果代码需要用于生产环境、团队协作或者长期维护，强烈建议修复，改为常规的类定义写法，避免后续出现维护、工具兼容类问题。

2. 该类定义风格和常规类定义风格的差异 #

这种增量重定义类的写法是专门适配Jupyter Notebook交互式开发场景的，和常规类定义风格的核心差异如下：

• 开发体验差异：Jupyter场景下可以把类的不同方法拆分到多个单元格分步编写，调试时不需要重跑整个类的全部代码，修改单个方法仅需要重新运行对应单元格即可；常规写法要求类的所有属性、方法一次性在同一个代码块中定义完成，修改方法需要重新运行整个类的定义代码。
• 可读性差异：常规写法仅需要查看单个类定义块就能获取类的完整结构，该增量写法需要按顺序查找所有同名类的定义代码才能梳理出类的完整成员，可读性极低。
• 维护成本差异：常规写法不存在定义顺序依赖，而该增量写法一旦重定义的顺序出错，或者漏掉某一步重定义的运行，就会直接出现逻辑错误，维护成本更高。
• 工具兼容性差异：常规写法可以被所有静态检查工具、IDE补全工具完美识别；该增量写法会导致Pylint这类静态检查工具误报，IDE的自动补全、代码跳转功能也会出现异常。
• 底层运行逻辑差异：该增量写法本质是每次基于前一个版本的同名类生成新的子类，再用新子类覆盖同名变量，过程中会生成无用的中间类；常规写法不会产生额外的中间对象。

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