摘要
自定义对象的布尔值真假,可以让我们的代码更pythonic; 善用 any() / all() 可以使代码更优雅简单;使用枚举替换数字,减少对裸字符串的操作可以使代码更加优雅和安全。
自定义对象的“布尔真假”
在 Python 中除了“万物皆对象”,还可以利用很多魔法方法(文档中称为:user-defined method),来自定义对象的各种行为。可以用很多在别的语言里面无法做到、有些魔法的方式来影响代码的执行。
如,Python 的所有对象都有自己的“布尔真假”:
布尔值为假的对象:None, 0, False, [], (), {}, set(), frozenset(), ... ...
布尔值为真的对象:非 0 的数值、True,非空的序列、元组,普通的用户类实例,... ...
通过内建函数 bool(),可以很方便的查看某个对象的布尔真假。而 Python 进行条件分支判断时用到的也是这个值:
>>> bool(object())
True
虽然所有用户类实例的布尔值都是真。但是 Python 提供了改变这个行为的办法:自定义类的 __bool__ 魔法方法 (在 Python 2.X 版本中为 __nonzero__)。当类定义了 __bool__ 方法后,它的返回值将会被当作类实例的布尔值。
另外,__bool__ 不是影响实例布尔真假的唯一方法。如果类没有定义 __bool__ 方法,Python 还会尝试调用 __len__ 方法(也就是对任何序列对象调用 len 函数),通过结果是否为 0 判断实例真假。
下面的代码片段:
class UserList(object):
def __init__(self, users):
self._users = users
users = UserList([piglei, raymond])
if len(users._users) > 0:
print("There's some users in List!")
改写为:
class UserList:
def __init__(self, users):
self._users = users
def __len__(self):
return len(self._users)
users = UserList(["bob", "raymond"])
# 定义了 __len__ 方法后,UserList 对象本身就可以被用于布尔判断了
if users:
print("There's some users in List!")
小结
通过定义魔法方法 __len__ 和 __bool__ ,可以让类自己控制想要表现出的布尔真假值,让代码变得更 pythonic。
在条件判断中使用 all() / any()
all() 和 any() 两个函数非常适合在条件判断中使用。这两个函数接受一个可迭代对象,返回一个布尔值,其中:
all(seq):仅当 seq 中所有对象都为布尔真时返回 True,否则返回 False
any(seq):只要 seq 中任何一个对象为布尔真就返回 True,否则返回 False
假如有下面这段代码:
def all_numbers_gt_100(numbers):
"""仅当序列中所有数字大于 100 时,返回 True
"""
if not numbers:
return False
for n in numbers:
if n <= 100:
return False
return True
如果使用 all() 内建函数,再配合一个简单的生成器表达式,上面的代码可以写成这样:
def all_numbers_gt_100(numbers):
return bool(numbers) and all(n > 100 for n in numbers)
小结
善用 any() / all() 可以使得代码更加简单、高效,同时也没有损失可用性。
使用枚举类型改善代码质量
enum 是 Python 自 3.4 版本引入的内置模块,如果使用的是更早的版本,可以通过 pip install enum34 来安装它。下面是使用 enum 的样例代码:
# -*- coding: utf-8 -*-
from enum import IntEnum
class TripSource(IntEnum):
FROM_WEBSITE = 11
FROM_IOS_CLIENT = 12
def mark_trip_as_featured(trip):
if trip.source == TripSource.FROM_WEBSITE:
do_some_thing(trip)
elif trip.source == TripSource.FROM_IOS_CLIENT:
do_some_other_thing(trip)
... ...
return
将重复出现的数字字面量定义成枚举类型,不光可以改善代码的可读性,代码出现 Bug 的几率也会降低。
试想一下,如果在某个分支判断时将 11 错打成了 111 会怎么样?时常会犯这种错,而这类错误在早期特别难被发现。将这些数字字面量全部放入枚举类型中可以比较好的规避这类问题。类似的,将字符串字面量改写成枚举也可以获得同样的好处。
小结
使用枚举类型代替字面量的好处:
提升代码可读性:所有人都不需要记忆某个神奇的数字代表什么
提升代码正确性:减少打错数字或字母产生 bug 的可能性
当然,也完全没有必要把代码里的所有字面量都改成枚举类型。 代码里出现的字面量,只要在它所处的上下文里面容易理解,就可以使用它。 比如那些经常作为数字下标出现的 0 和 -1 就完全没有问题,因为所有人都知道它们的意思。
减少裸字符串处理的使用
“裸字符串处理”指 只是使用基本的加减乘除和循环、配合内置函数/方法来操作字符串,获得我们需要的结果。
所有人都写过这样的代码。有时候需要拼接一大段发给用户的告警信息,有时我们需要构造一大段发送给数据库的 SQL 查询语句,就像下面这样:
def fetch_users(conn, min_level=None, gender=None, has_membership=False, sort_field="created"):
"""获取用户列表
:param int min_level: 要求的最低用户级别,默认为所有级别
:param int gender: 筛选用户性别,默认为所有性别
:param int has_membership: 筛选所有会员/非会员用户,默认非会员
:param str sort_field: 排序字段,默认为按 created "用户创建日期"
:returns: 列表:[(User ID, User Name), ...]
"""
# 一种古老的 SQL 拼接技巧,使用 "WHERE 1=1" 来简化字符串拼接操作
# 区分查询 params 来避免 SQL 注入问题
statement = "SELECT id, name FROM users WHERE 1=1"
params = []
if min_level is not None:
statement += " AND level >= ?"
params.append(min_level)
if gender is not None:
statement += " AND gender >= ?"
params.append(gender)
if has_membership:
statement += " AND has_membership == true"
else:
statement += " AND has_membership == false"
statement += " ORDER BY ?"
params.append(sort_field)
return list(conn.execute(statement, params))
之所以用这种方式拼接出需要的字符串 - 在这里是 SQL 语句 - 是因为这样做简单、直接,符合直觉。但是这样做最大的问题在于:随着函数逻辑变得更复杂,这段拼接代码会变得容易出错、难以扩展。事实上,上面这段 Demo 代码也只是仅仅做到看上去没有明显的 bug 而已 (谁知道有没有其他隐藏问题)。
其实,对于 SQL 语句这种结构化、有规则的字符串,用对象化的方式构建和编辑它才是更好的做法。下面这段代码用 SQLAlchemy 模块完成了同样的功能:
def fetch_users_v2(conn, min_level=None, gender=None, has_membership=False, sort_field="created"):
"""获取用户列表
"""
query = select([users.c.id, users.c.name])
if min_level is not None:
query = query.where(users.c.level >= min_level)
if gender is not None:
query = query.where(users.c.gender == gender)
query = query.where(users.c.has_membership == has_membership).order_by(users.c[sort_field])
return list(conn.execute(query))
上面的 fetch_users_v2 函数更短也更好维护,而且根本不需要担心 SQL 注入问题。
小结
当代码中出现复杂的裸字符串处理逻辑时,请试着用下面的方式替代它:
Q: 目标/源字符串是结构化的,遵循某种格式吗?
是:找找是否已经有开源的对象化模块操作它们,或是自己写一个
SQL:SQLAlchemy
XML:lxml
JSON、YAML ...
否:尝试使用模板引擎而不是复杂字符串处理逻辑来达到目的
Jinja2
Mako
Mustache