我经常使用 Python 的 assert 语句来检查用户输入，如果处于损坏状态就快速失败。我知道当 Python 使用 -o（优化）标志时会删除 assert。尽管我个人不会在优化模式下运行任何应用程序，但感觉还是应该避免使用 assert，以防万一。
使用 assert 后代码看起来更加简洁
assert filename.endswith('.jpg')
if not filename.endswith('.jpg'):
raise RuntimeError
这是否是assert的有效用例？如果不是，那么Python的assert语句的有效用例是什么？
断言应该用于表达不变量或前置条件。
在你的示例中，你使用它们来检查意外输入——这是完全不同的异常类。
根据要求，如果出现错误的输入，引发异常并停止应用程序可能是完全可以的；然而，代码应该始终为表达性而定制，引发AssertionError并不够明确。
更好的做法是引发自己的异常或ValueError。
assert 来实现这一点。 - Jason Orendorffif expr: raise ValueError 是一行完全有效的代码。如果您有问题，请开一个单独的问题。 - S.Lottassert <condition>，“无效参数值：<details>”？ - ivan_pozdeevassert。 - rob如果优雅不可行，那就要戏剧化
这是您的代码的正确版本：
if filename.endswith('.jpg'):
# convert it to the PNG we want
try:
filename = convert_jpg_to_png_tmpfile(filename)
except PNGCreateError:
# Tell the user their jpg was crap
print "Your jpg was crap!"
在我看来，以下情况是有效的：
否则，要处理可能性，因为你可以预料到它会发生。
ASSERT == "这应该永远不会在现实中发生，如果确实发生了，我们放弃"
当然，这不同于：
#control should never get here
但我总是这么做
#control should never get here
#but i'm not 100% putting my money where my mouth
#is
assert(False)
这样我就会得到一个清晰的错误信息。在你的例子中，我会使用if语句版本并将文件转换为jpg！
assert False而不是assert(False)，因为assert是一个语句而不是函数（在Python 2和3中都是如此）。 - kratenko完全有效。这个断言是关于程序状态的正式声明。
您应该将它们用于无法证明的事情。然而，对于您认为可以证明的事情，它们非常方便，可以作为逻辑检查。
另一个例子。
def fastExp( a, b ):
assert isinstance(b,(int,long)), "This algorithm raises to an integer power"
etc.
又一个。最后的断言有点儿可笑，因为它应该是可以被证明的。
# Not provable, essential.
assert len(someList) > 0, "Can't work with an empty list."
x = someList[]
while len(x) != 0:
startingSize= len(x)
... some processing ...
# Provable. May be Redundant.
assert len(x) < startingSize, "Design Flaw of the worst kind."
def sqrt( x ):
# This may not be provable and is essential.
assert x >= 0, "Can't cope with non-positive numbers"
...
# This is provable and may be redundant.
assert abs( n*n - x ) < 0.00001
return n
制作正式断言有许多理由。
raise ValueError，我原以为这是用于无效参数的？ - Demisassert而言，这一点更加明显。与C++/C#不同的是，Python的assert语句被有机地纳入到代码的自然控制流中，而不会使程序不优雅地中断/终止。 - ivan_pozdeevassert最适用于在测试期间需要使用的代码，当您确定不会运行-o时。
您个人可能永远不会运行-o，但如果您的代码最终进入更大的系统，并且管理员想要使用-o来运行它，那将会发生什么？
系统可能看起来运行良好，但是由于使用-o而被激活的微妙错误可能会出现。
就个人而言，我会在遇到意外错误或者在实际使用中不太可能发生的情况下使用assert。而在处理来自用户或文件的输入时，应该使用异常，因为它们可以被捕获并告诉用户“嘿，我期望的是一个.jpg文件！”
AssertionError 确实是一个异常... （而且，它是一个 Exception ；-)） - ivan_pozdeevdef sqrt(x):
if x<0:
raise ValueError, 'sqrt requires positive numbers'
root = <do stuff>
return root
def some_func(x):
y = float(raw_input('Type a number:'))
try:
print 'Square root is %f'%sqrt(y)
except ValueError:
# User did not type valid input
print '%f must be a positive number!'%y
然而，这会带来性能损失。想象一下像这样的代码：
def sqrt(x):
if x<=0:
raise ValueError, 'sqrt requires positive numbers'
root = <do stuff>
return root
def some_func(maxx=100000):
all_sqrts = [sqrt(x) for x in range(maxx)]
i = sqrt(-1.0)
return(all_sqrts)
# This function valid if x > 0
def sqrt(x):
root = <do stuff>
return root
def long_function(maxx=100000):
# This is a valid function call - every x i pass to sqrt is valid
sqrtlist1 = [sqrt(x) for x in range(maxx)]
# This one is a program error - calling function with incorrect arguments
# But one that can't be statically determined
# It will throw an exception somewhere in the sqrt code above
i = sqrt(-1.0)
assert 辩护。更像是在说明它在 Python 之前的一些关注代码性能胜过正确性的语言中有其存在的意义，因此在 Python 中，它的原始用例已经成为了退化的。 - ivan_pozdeev底线：
assert及其语义是早期语言的遗产。ASSERT语句最初被创建的预期用途为：
free()是否传递了先前从malloc()获取的指针，对它们进行非平凡操作后的内部结构完整性检查等。这在旧有的环境中曾经是一件大事，现在在为性能而设计的环境中仍然如此。这是C++/C#中其语义的全部原因：
然而，Python有意识地为了程序员的表现而牺牲了代码性能（信不信由你，我最近通过将一些代码从Python移植到Cython获得了100倍的加速 - 甚至没有禁用边界检查！）。Python代码在“安全”环境中运行，因此您无法完全“破坏”进程（或整个系统）以致于无法跟踪的段错误/BSoD/砖化 - 最糟糕的情况是会出现一个未处理的异常，并附带大量调试信息，以可读的形式优雅地呈现给您。