一直想写一篇介绍 attrs
的文章,但是最近几个月忙于做爱湃森课程实在抽不出空来做,最近感觉找到节奏了,还是稳步向前走了,这个周末就硬挤了一下午写写,要不感觉对不起订阅专栏的同学们。
在国内我没见过有同学说这2个东西,它们是什么,又有什么关联呢?别着急,先铺垫一下他俩出现的背景。
痛点
写多了Python,尤其是开发和微信的项目比较大的时候,你可能和我一样感觉写Python的类很累。怎么累呢?举个例子,现在有个商品类,init是这么写的:
1 |
|
问题1:特点是初始化参数很多,每一个都需要self.xx = xx 这样往实例上赋值。我印象见过一个类有30多个参数,这个 init
方法下光是赋值就占了一屏多…
再说问题2,如果不定义repr方法,打印类对象的方式很不友好,大概是这样的:
1 |
|
定义时参数太多,一般按需要挑几个露出来:
1 |
|
这样再看类对象就友好了:
1 |
|
但是每个类都需要手动的去写repr!
接着说问题3,对象比较,有时候需要判断2个对象是否相等甚至大小(例如用于展示顺序):
1 |
|
如果对比的更全面不用所有gt、gte、lte都写出来,用functools.total_ordering这样就够了:
1 |
|
然后是问题4。有些场景下希望对对象去重,可以添加hash:
1 |
|
这样就不需要对一大堆的对象挨个比较去重了,直接用集合就可以了:
1 |
|
可以看到集合只返回了一个对象,另外一个被去掉了。
最后是问题5。我很喜欢给类写一个to_dict、to_json或者as_dict这样的方法,把类里面的属性打包成一个字典返回。基本都是每个类都要写一遍它:
1 |
|
当然没有特殊的理由,可以直接使用vars(self)获得, 上面这种键值对指定的方式会更精准,只导出想导出的部分,举个特殊的理由吧:
1 |
|
会把_a也包含在返回的结果中,然而它并不应该被导出,所以不适合vars函数。
到这里,我们停下来想想,self.id、self.author_id、self.category_id 这些分别写了几次?
那有没有一种方法,可以在创建类的时候自动给类加上这些东西,把开发者解脱出来呢?这就是我们今天介绍的attrs和Python
3.7标准库里面将要加的dataclasses模块做的事情,而且它们能做的会更多。
attrs
attrs是Python核心开发Hynek
Schlawack设计并实现的一个项目,它就是解决上述痛点而生的,上述类,使用attrs这样写:
1 |
|
这就可以了,上面说的那些dunder方法(双下划线开头和结尾的方法)都不用写了:
1 |
|
是不是清爽直观?
当然, 我这个例子中对属性的要求比较多,所以不同属性的参数比较长。看这个类的定义的方式是不是有点像ORM?对象和属性的关系直观,不参与类中代码逻辑。
有兴趣的可以看[Kenneth Reitz、Łukasz Langa、Glyph Lefkowitz等人对项目的评价]
(http://www.attrs.org/en/stable/index.html#testimonials)。
除此之外,attrs 还支持多种高级用法,如字段类型验证、自动类型转化、属性值不可变(Immutability)、类型注解等等 ,我列3个我觉得非常有用的吧
字段类型验证
业务代码中经验会对对象属性的类型和内容验证,attrs也提供了验证支持。验证有2种方案:
- 装饰器
1 |
|
- 属性参数:
1 |
|
属性类型转化
Python不会检查传入的值的类型,类型错误很容易发生,attrs支持自动的类型转化:
1 |
|
包含元数据
属性还可以包含元数据!这个真的非常有用,这个属性的值就不仅仅是一个值了,带上元数据的值非常灵活也更有意义,这样就不需要额外的把属性需要的元数据独立存储起来了。
1 |
|
通过上面支持的几个功能可以看出作者做项目就是基于实际工作痛点出发的。
dataclasses模块
在Python 3.7里面会添加一个新的模块
dataclasses
,它基于PEP 557,Python
3.6可以通过pip下载安装使用:
1 |
|
解决如上痛点,把Product类改成这样:
1 |
|
先验证一下:
1 |
|
dataclasses.asdict不能过滤返回属性。但是总体满足需求。但是,你有没有发现什么不对?
attrs 和 dataclasses
虽然2种方案写的代码确实有些差别,但有木有觉得它俩很像?其实attrs 的诞生远早于 dataclasses,
dataclasses更像是在借鉴。dataclasses可以看做是一个 强制类型注解,功能是attrs的子集 。那么为什么不把 attrs
放入标准库,而是Python 3.7加入一个阉割版的 attrs 呢?
Glyph Lefkowitz犀利的写了标题为why not just
attrs?的issue,我打开这个issue没往下看的时候,猜测是「由于attrs兼容Python3.6,包含Python2.7的版本,进入标准库必然是一次卸掉包袱的重构,attrs作者不同意往这个方向发展?」,翻了下讨论发现不是这样的。
这个issue很有意思,多个Python开发都参与进来了,最后Gvanrossum结束了讨论,明确表达不同意 attrs 进入标准库,Donald
Stufft也直接问了为啥?Gvanrossum虽然解释了下,但是我还是觉得这算是「仁慈的独裁者」中的「独裁」部分的体现吧,Python社区的态度一直是不太开放。包含在
PEP 557 下[解释为什么不用
attrs](https://www.python.org/dev/peps/pep-0557/#why-not-just-use-
attrs),也完全说服不了我。
我站 attrs,向大家推荐! 不仅是由于attrs兼容之前的Python版本,而是attrs是真的站在开发者的角度上添加功能支持,最后相信 attrs
会走的更远。
参考文章
- http://www.attrs.org/en/stable/index.html
- https://glyph.twistedmatrix.com/2016/08/attrs.html
- https://www.python.org/dev/peps/pep-0557/
版权声明:本文由 董伟明 原创,未经作者授权禁止任何微信公众号和向掘金(juejin.im)转载,技术博客转载采用 保留署名-非商业性使用-禁止演绎 4.0-国际许可协议
python