class Action(XIntegerChoices):
""" 动作 枚举类 """
CREATE = 0, "创建"
DELETE = 1, "删除"
UPDATE = 2, "修改"
RETRIEVE = 3, "查看"
LIKE = 4, "点赞"
FOLLOW = 5, "关注"
COLLECT = 6, "收藏"
REGISTER = 7, "注册"
LOGIN = 8, "登录"
SEND = 9, "发送"
CANCEL = 10, "取消"
PEP 8: E221 multiple spaces before operator
(所以最后用 # noqa
来使 IDE 不检查,从而不飘黄)class Action(XIntegerChoices):
""" 动作 枚举类 """
CREATE = 0, "创建" # noqa
DELETE = 1, "删除" # noqa
UPDATE = 2, "修改" # noqa
RETRIEVE = 3, "查看" # noqa
LIKE = 4, "点赞" # noqa
FOLLOW = 5, "关注" # noqa
COLLECT = 6, "收藏" # noqa
REGISTER = 7, "注册" # noqa
LOGIN = 8, "登录" # noqa
SEND = 9, "发送" # noqa
CANCEL = 10, "取消" # noqa
1
chaoshui 2023-07-19 14:30:44 +08:00 1
老老实实第一种
|
2
zqguo 2023-07-19 14:47:14 +08:00
第二种不知道有啥好?强行工整?
|
3
vicalloy 2023-07-19 14:47:24 +08:00 2
在 precommit 里设置代码提交前用 black 自动格式化。
没必要在这类无关紧要的地方折腾。 |
5
XueXianqi OP @zqguo
我是看一些第三方库的时候看到这种 “强行工整” 的枚举类写法 colorma.ansi.py 第 49 行 class AnsiFore(AnsiCodes): BLACK = 30 RED = 31 GREEN = 32 YELLOW = 33 BLUE = 34 MAGENTA = 35 CYAN = 36 WHITE = 37 RESET = 39 (复制过来可能没对齐,可以忽略...) 然后就在想,有没有必要这样 |
7
mainjzb 2023-07-19 15:03:37 +08:00
🤣go 会强制对齐。希望其他语言能学习。
|
8
busier 2023-07-19 15:10:32 +08:00
这样的操作,塞到数组里面不行么!!!
|
9
hello00001 2023-07-19 15:13:41 +08:00
ctrl + alt + l
|
10
asmoker 2023-07-19 15:23:03 +08:00
换 go ,go 是第二种 🤨
|
11
XueXianqi OP @hello00001 格式化代码,肯定是默认的第一种的...
|
13
lysS 2023-07-19 15:24:38 +08:00
肯定是第二种啊
|
14
joApioVVx4M4X6Rf 2023-07-19 15:39:44 +08:00
有什么格式化方法能把代码格式化成第二种
|
15
Leviathann 2023-07-19 15:48:12 +08:00
然后新加一个名字更长的整个文件 git 全改是吧
|
16
wuwukai007 2023-07-19 16:00:25 +08:00
class Choices:
def __init__(self, value, name): self._value = value self._name = name @property def value(self): return self._value @property def name(self): return self._name def __eq__(self, other): return self._value == other def __ne__(self, other): return not self.__eq__(other) class Action: """ 动作 枚举类 """ CREATE = Choices(0, "创建") DELETE = Choices(1, "删除") # 使用 x = 0 # 判断值 if x == Action.CREATE: print("匹配创建操作") # 获取名称 print(Action.CREATE.name) |
18
XueXianqi OP @wuwukai007
谢谢~ 我也自己封装过枚举基类,康康我的这个写得怎么样: https://gitee.com/xuexianqi/x_utils/blob/master/enum_utils/base.py |
19
XueXianqi OP @Leviathann 确实,方式 2 对 git 不太友好,牵一发而动全身
|
21
ruanimal 2023-07-19 17:21:16 +08:00
话说你这个 tuple 不加括号,有点恶心
|
22
XueXianqi OP @ruanimal
这个是参考 Django 的枚举类: https://docs.djangoproject.com/zh-hans/4.2/ref/models/fields/#enumeration-types 其他的一些枚举类也有部分是如此,是隐式的 对于新手来说确实不够友好... |
23
apake 2023-07-19 19:15:44 +08:00
第二种看的更清楚, 更省脑子. 所以第二种.
|
24
kingcanfish 2023-07-20 00:42:26 +08:00
来写 golang 你就不会有这个烦恼了
|
25
justdoit123 2023-07-20 10:38:03 +08:00
没调教出格式化工具,就老老实实用第一种。
|
26
iosyyy 2023-07-20 11:16:21 +08:00
在这两种对齐方式中,第一种方式(方式 1 )通常比第二种方式(方式 2 )更受推荐,原因如下:
可读性:第一种方式允许变量名的长度自然变化,使得代码更易读和理解。当变量名长度不一致时,对齐会导致外观上不够整齐,但通常更直观和美观。 代码规范:第一种方式符合 PEP 8 代码风格指南,这是 Python 代码的官方风格指南。PEP 8 建议避免在赋值等号(在这种情况下)之前使用多个空格。虽然第二种方式尝试通过 # noqa 来忽略代码检查警告,但最好在可能的情况下避免与代码规范冲突。 可维护性:如果未来添加或修改变量,第一种方式会自动适应变化,而第二种方式可能需要手动调整对齐,如果不仔细处理可能引入错误。 一致性:第一种方式更符合典型的 Python 代码风格,遵循大多数 Python 项目中使用的标准缩进做法。 总体而言,通常更应该优先考虑可读性、可维护性和代码规范,而不是严格的对齐。第一种方式允许灵活处理变量名长度,同时提供更干净、符合标准的代码风格。 |
29
iorilu 2023-07-20 13:24:20 +08:00 via Android
这代码是用什么框架吗
|
30
XueXianqi OP @iorilu
这个代码不依赖于框架。 可以单独提出来用,也可以用在 Django 、Flask 、FastAPI 里面(例如 Django 的 Model 的 choices ) 这是自己封装的枚举基类: https://gitee.com/xuexianqi/x_utils/blob/master/enum_utils/base.py |
31
l4ever 2023-07-28 10:00:11 +08:00
何必纠结这些, IDE 说了算, 一保存就自动格了.
管你嘞 |