python中val是什么_在Python中什么时候建议使用ret_val变量？

关于以下代码是否更好,我看到了相互矛盾的建议

def function():

ret_val = 0

if some_condition():

ret_val = 2

else:

ret_val = 3

return ret_val

或者这是否更好：

def function():

if some_condition():

return 2

else:

return 3

这是一个简单的例子,我用python风格编写它,但我正在寻找的一般原则是什么时候使用一些“累加器”变量来跟踪返回值,或者是否使用多个出口点.我知道不同的语言可能有不同的原因使用一种风格而不是另一种风格,所以我很欣赏不同的观点,为什么特定的语言可能会坚持特定的风格. (特别是在过去,我听说C中的结构化编程避免了函数的多个退出点.)

我们忘记了为什么“多个出口点”首先被认为是有害的吗？回到当天(在广泛访问良好的异常处理和最终构造之前,或管理像auto_ptr这样的对象,当它们离开作用域时进行清理),这是困扰许多多退出函数的问题：

int function blah(arg1, arg2)

allocate resource

if early failure detection

return failure_status

... much later...

release resource // oh rats! resource didn't release

return success_status

如果资源是内存,则会产生内存泄漏.如果它是数据库事务,我们正在走向错误的数据库争用或死锁.就此而言,随着更多异常支持的出现,我们隐式地从方法中添加了许多潜在的退出(由于未处理的异常).在我的C日里,我养成了从不调用delete的习惯,而是使用auto_ptr,以便在auto_ptr退出其作用域时清除已分配的内存,即使某些意外异常抬头.

在我们的垃圾收集Python世界中,我们仍然可以遇到这个问题,即使我们的许多对象(如文件或锁)都改进了自清洁行为.但是在CPython以外的实现中(jython和IronPython命名为2),不能保证析构函数何时被调用,因此需要在方法中构建更主动的东西.为此目的的第一个机制是try / finally：

int function blah(arg1, arg2)

allocate resource

try:

if early failure detection

return failure_status

... much later...

return success_status

finally:

release resource // always releases no matter what

但是现在Python有了上下文管理器,结合了新的’with’语法：

int function blah(arg1, arg2)

allocate resource

with context_manager(resource): // releases on exit from 'with'

if early failure detection

return failure_status

... much later...

return success_status

因此,让我们确定我们告诉整个故事,我们可以抛弃这个旧板栗的原因是新的编码实践使它变得不必要.