[CodeStyle][PLR0402][C405]

[yllhwa]

PR types

Others

PR changes

Others

Describe

补充修复未完成的[PLR0402][C405]style fix。
修复后运行ruff check .将没有错误。
From: #51729

[paddle-bot]

你的PR提交成功，感谢你对开源项目的贡献!
请关注后续CI自动化测试结果，详情请参考Paddle-CI手册。
Your PR has been submitted. Thanks for your contribution!
Please wait for the result of CI firstly. See Paddle CI Manual for details.

[CLAassistant]

All committers have signed the CLA.

[SigureMo]

相关增量我已经在 #52140 处理了，最新的 develop 运行 ruff . 已经不会报错了

可以考虑新增别的 rule～比如 Bugbear 的还有很多没有认领～

[yllhwa]

好的，请问你觉得PLW2901是否适合引入呢？
@SigureMo
例如

for ut in data:
        ut = ut.replace('\n', '').strip()
        if ut not in files:
            print(ut)

可以修改为

for ut in data:
      ut_stripped = ut.replace('\n', '').strip()
      if ut_stripped not in files:
          print(ut_stripped)

如果引入的话，这种类型的错误应当如何处理呢？

for pair in string.split(","):
        if pair.startswith("("):
            pair = pair[1:]
        return pair # 此处使用的变量可能并没有经过修改

[SigureMo]

首先，我们引入一条 rule 是用来规避可能出现的 bug 的，但不能因为引入过于严格的 rule 增加写代码的负担

这条 rule 的话，首先存量过多，不带自动修复，手动修复可能会花费大量时间，另外如果引入，开发者如果遇到相关 case 解决起来可能会比较麻烦，会增加开发的成本

而且，目前大多数 case 我觉得并不会导致 bug，如果真的发现 bug，我们可以对这些 case 单独修复，这条 rule 的话还是不引入比较好

[paddle-bot]

很抱歉，经过我们的反复讨论，你的PR暂未达到合入标准，请阅读飞桨原生算子开发规范，你可以重新提交新的PR，我们先将此PR关闭，感谢你的贡献。
Sorry to inform you that through our discussion, your PR fails to meet the merging standard (Reference: Paddle Custom Operator Design Doc). You can also submit an new one. Thank you.

[luotao1]

@yllhwa 有兴趣继续尝试下B017、PLR5501、PLR0206么？

[yllhwa]

对于PLR5501（Consider using elif instead of else then if to remove one indentation level），其要求将类似

if isinstance(d, type):
      # This branch is for NumPy scalar types
else:
      # This branch is for np.dtype and str
      if d in ['float16', 'float32', 'float64', 'bfloat16']:
          d = str(d)
      else:
          raise TypeError()

的代码修改为

if isinstance(d, type):
    # This branch is for NumPy scalar types
elif d in ['float16', 'float32', 'float64', 'bfloat16']:
    d = str(d)
else:
    raise TypeError()

理由是这样可以减少一个缩进，但我觉得这样是不是损失了一定的可读性呢？

此外该style存量的错误有223个，相对较多，且ruff不带自动修复，是否可以考虑不引入该style check。

[SigureMo]

理由是这样可以减少一个缩进，但我觉得这样是不是损失了一定的可读性呢？

嗯，考虑到类似 case 的话确实不太建议引入，感谢调研～

[yllhwa]

对于PLR0206（Cannot have defined parameters for properties）。

事实上引发报错的只有

Paddle/test/dygraph_to_static/simnet_dygraph_model.py

Lines 366 to 369 in b0dbf9f

	# TODO(songyouwei): We should remove _w property
	@property
	def _w(self, i=0):
	return self.__w[i]

和

Paddle/test/dygraph_to_static/simnet_dygraph_model_v2.py

Lines 352 to 355 in b0dbf9f

	# TODO(songyouwei): We should remove _w property
	@property
	def _w(self, i=0):
	return self.__w[i]

我认为该规则可以引入，但是这个代码引入于很久以前的f9ac5fb9925a，结合上面的注释，没有修改是有兼容性还是什么方面的考虑吗？

[SigureMo]

我认为该规则可以引入，但是这个代码引入于很久以前的f9ac5fb9925a，结合上面的注释，没有修改是有兼容性还是什么方面的考虑吗？

我认为这个 _w 的 getter 和 setter 都可以删除了，_w 从未被使用过，可以移除看看是否可以通过单测