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