原文:http://blog.jobbole.com/76285/

本文由 伯乐在线 - 贱圣OMG 翻译。未经许可,禁止转载!
英文出处:python maillist。欢迎加入翻译小组

这个问题是如何在一些场景下使用断言表达式,通常会有人误用它,所以我决定写一篇文章来说明何时使用断言,什么时候不用。

为那些还不清楚它的人,Python的assert是用来检查一个条件,如果它为真,就不做任何事。如果它为假,则会抛出AssertError并且包含错误信息。例如:

py> x = 23
py> assert x > 0, "x is not zero or negative"
py> assert x%2 == 0, "x is not an even number"
Traceback (most recent call last):
File "", line 1, in
AssertionError: x is not an even number

很多人用assert作为一个很快和容易的方法来在参数错误的时候抛出异常。但这样做是错的,非常错误,有两个原因。首先AssertError不是在测试参数时应该抛出的错误。你不应该像这样写代码:

if not isinstance(x, int):
raise AssertionError("not an int")

你应该抛出TypeError的错误,assert会抛出错误的异常。

但是,更危险的是,有一个关于assert的困扰:它可以被编译好然后从来不执行,如果你用 –O 或 –oo 选项运行Python,结果不保证assert表达式会运行到。当适当的使用assert时,这是未来,但是当assert不恰当的使用时,它会让代码用-O执行时出错。

那什么时候应该使用assert?没有特定的规则,断言应该用于:

  • 防御型的编程
  • 运行时检查程序逻辑
  • 检查约定
  • 程序常量
  • 检查文档

(在测试代码的时候使用断言也是可接受的,是一种很方便的单元测试方法,你接受这些测试在用-O标志运行时不会做任何事。我有时在代码里使用assert False来标记没有写完的代码分支,我希望这些代码运行失败。尽管抛出NotImplementedError可能会更好。)

关于断言的意见有很多,因为它能确保代码的正确性。如果你确定代码是正确的,那么就没有用断言的必要了,因为他们从来不会运行失败,你可以直接移除这些断言。如果你确定检查会失败,那么如果你不用断言,代码就会通过编译并忽略你的检查。

在以上两种情况下会很有意思,当你比较肯定代码但是不是绝对肯定时。可能你会错过一些非常古怪的情况。在这个情况下,额外的运行时检查能帮你确保任何错误都会尽早地被捕捉到。

另一个好的使用断言的方式是检查程序的不变量。一个不变量是一些你需要依赖它为真的情况,除非一个bug导致它为假。如果有bug,最好能够尽早发现,所以我们为它进行一个测试,但是又不想减慢代码运行速度。所以就用断言,因为它能在开发时打开,在产品阶段关闭。

一个非变量的例子可能是,如果你的函数希望在它开始时有数据库的连接,并且承诺在它返回的时候仍然保持连接,这就是函数的不变量:

def some_function(arg):
assert not DB.closed()
... # code goes here
assert not DB.closed()
return result

断言本身就是很好的注释,胜过你直接写注释:

# when we reach here, we know that n > 2

你可以通过添加断言来确保它:

assert n > 2

断言也是一种防御型编程。你不是让你的代码防御现在的错误,而是防止在代码修改后引发的错误。理想情况下,单元测试可以完成这样的工作,可是需要面对的现实是,它们通常是没有完成的。人们可能在提交代码前会忘了运行测试代码。有一个内部检查是另一个阻挡错误的防线,尤其是那些不明显的错误,却导致了代码出问题并且返回错误的结果。

加入你有一些if…elif 的语句块,你知道在这之前一些需要有一些值:

# target is expected to be one of x, y, or z, and nothing else.
if target == x:
run_x_code()
elif target == y:
run_y_code()
else:
run_z_code()

假设代码现在是完全正确的。但它会一直是正确的吗?依赖的修改,代码的修改。如果依赖修改成 target = w 会发生什么,会关系到run_w_code函数吗?如果我们改变了代码,但没有修改这里的代码,可能会导致错误的调用 run_z_code 函数并引发错误。用防御型的方法来写代码会很好,它能让代码运行正确,或者立马执行错误,即使你在未来对它进行了修改。

在代码开头的注释很好的一步,但是人们经常懒得读或者更新注释。一旦发生这种情况,注释会变得没用。但有了断言,我可以同时对代码块的假设书写文档,并且在它们违反的时候触发一个干净的错误

assert target in (x, y, z)
if target == x:
run_x_code()
elif target == y:
run_y_code()
else:
assert target == z
run_z_code()

这样,断言是一种防御型编程,同时也是一种文档。我想到一个更好的方案:

if target == x:
run_x_code()
elif target == y:
run_y_code()
elif target == z:
run_z_code()
else:
# This can never happen. But just in case it does...
raise RuntimeError("an unexpected error occurred")

按约定进行设计是断言的另一个好的用途。我们想象函数与调用者之间有个约定,比如下面的:

“如果你传给我一个非空字符串,我保证传会字符串的第一个字母并将其大写。”

如果约定被函数或调用这破坏,代码就会出问题。我们说函数有一些前置条件和后置条件,所以函数就会这么写:

def first_upper(astring):
assert isinstance(astring, str) and len(astring) > 0
result = astring[0].upper()
assert isinstance(result, str) and len(result) == 1
assert result == result.upper()
return result

按约定设计的目标是为了正确的编程,前置条件和后置条件是需要保持的。这是断言的典型应用场景,因为一旦我们发布了没有问题的代码到产品中,程序会是正确的,并且我们能安全的移除检查。

下面是我建议的不要用断言的场景:

  • 不要用它测试用户提供的数据
  • 不要用断言来检查你觉得在你的程序的常规使用时会出错的地方。断言是用来检查非常罕见的问题。你的用户不应该看到任何断言错误,如果他们看到了,这是一个bug,修复它。
  • 有的情况下,不用断言是因为它比精确的检查要短,它不应该是懒码农的偷懒方式。
  • 不要用它来检查对公共库的输入参数,因为它不能控制调用者,所以不能保证调用者会不会打破双方的约定。
  • 不要为你觉得可以恢复的错误用断言。换句话说,不用改在产品代码里捕捉到断言错误。
  • 不要用太多断言以至于让代码很晦涩。

关于作者: 贱圣OMG

Python中何时使用断言(转)的更多相关文章

  1. Python中何时使用断言

    这个问题是如何在一些场景下使用断言表达式,通常会有人误用它,所以我决定写一篇文章来说明何时使用断言,什么时候不用. 为那些还不清楚它的人,Python的assert是用来检查一个条件,如果它为真,就不 ...

  2. Python中何时使用断言 assert

    使用断言的最佳时机偶尔会被提起,通常是因为有人误用,因此我觉得有必要写一篇文章来阐述一下什么时候应该用断言,为什么应该用,什么时候不该用. 对那些没有意识到用断言的最佳时机的人来说,Python的断言 ...

  3. Python中不尽如人意的断言Assertion

    Python Assert 为何不尽如人意 Python中的断言用起来非常简单,你可以在assert后面跟上任意判断条件,如果断言失败则会抛出异常. >>> assert 1 + 1 ...

  4. 【转】Python中不尽如人意的断言Assertion

    原文地址:Python中不尽如人意的断言Assertion Python Assert 为何不尽如人意 Python中的断言用起来非常简单,你可以在assert后面跟上任意判断条件,如果断言失败则会抛 ...

  5. python中那个断言assert的优化

    Python Assert 为何不尽如人意# Python中的断言用起来非常简单,你可以在assert后面跟上任意判断条件,如果断言失败则会抛出异常. Copy >>> assert ...

  6. Python爬虫学习(4): python中re模块中的向后引用以及零宽断言

    使用小括号的时候,还有很多特定用途的语法.下面列出了最常用的一些: 表4.常用分组语法 分类 代码/语法 说明 捕获 (exp) 匹配exp,并捕获文本到自动命名的组里 (?<name>e ...

  7. Python学习-41.Python中的断言

    先来点题外话: 在现代编程开发中,TDD(测试驱动开发)变得越来越流行(PS:DDD(领域驱动开发)也是,但两者并不冲突,就像面向过程和面向对象).而作为TDD的根本——单元测试也是越来越重要,单元测 ...

  8. 第11.20节 Python 中正则表达式的扩展功能:后视断言、后视取反

    一. 引言 在<第11.19节 Python 中正则表达式的扩展功能:前视断言和前视取反>中老猿介绍了前视断言和前视取反,与二者对应的还有后视断言和后视取反. 二. (?<=-)后视 ...

  9. Python::re 模块 -- 在Python中使用正则表达式

    前言 这篇文章,并不是对正则表达式的介绍,而是对Python中如何结合re模块使用正则表达式的介绍.文章的侧重点是如何使用re模块在Python语言中使用正则表达式,对于Python表达式的语法和详细 ...

随机推荐

  1. 04-1下载Win系统(装机助理)

    下载Win系统(装机助理): http://www.zhuangjizhuli.com/upan.html http://www.krlxx.com/64win7.html 选择你需要安装的系统: 以 ...

  2. spring实现定时任务

    今天在项目里需要实现一个定时任务,每隔3个小时将过滤的广告通过邮件上报给运营一次.考虑了一下,从实现的技术上可以有三种做法: 1.Java自带的java.util.Timer类,这个类允许调度一个ja ...

  3. Spring mvc 注解@ResponseBody 返回内容编码问题

    @ResponseBody 在@Controller 类方法中能够让字符串直接返回内容. 其返回处理的类是org.springframework.http.converter.StringHttpMe ...

  4. 初识Quartz(一)

    首先需要一个任务: ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 package quartz_proj ...

  5. php类库PHP QR Code 二维码

    php类库PHP QR Code 二维码 php类库PHP QR Code 二维码 php类库PHP QR CodePHP QR Code is open source (LGPL) library ...

  6. iOS中解析Bonjour服务(转)

    服务器端Bonjour服务发布成功之后,客户端可以通过NSNetService解析服务,解析成功后,可以获得通讯的数据细节,如:IP地址.端口等信息. 首先需要实例化NSNetService对象代码如 ...

  7. windows2008,命令行远程登录

    命令行强制开启3389服务支持server2008和2003 1.C:\Windows\System32\wbem\wmic /namespace:\\root\cimv2\terminalservi ...

  8. Death to Binary? 分析模拟

    /** 题目:Death to Binary? 链接:https://vjudge.net/contest/154246#problem/T 题意:略. 思路: 注意事项: 给的字符串存在前导0: 存 ...

  9. quantz入门和使用流程(转载)

    1.下载地址:http://quartz-scheduler.org/downloads/catalog http://quartz-scheduler.org/downloads/destinati ...

  10. Java基础04 封装与接口(转载)

    数据成员和方法都是同时开放给内部和外部的.在对象内部,我们利用this来调用对象的数据成员和方法.在对象外部,比如当我们在另一个类中调用对象的时,可以使用 对象.数据成员 和 对象.方法() 来调用对 ...