Python和一本愚蠢的教科书中的命名条件-以及如何证明它们是错误的

如何解决Python和一本愚蠢的教科书中的命名条件-以及如何证明它们是错误的

许多人经常将Python的抽象视为魔术。我来自C的背景，我很清楚，没有魔术之类的东西，只有由简单的组件组成的冷硬代码才能产生抽象。

因此，当教科书和我的老师说我们可以“存储条件”或使用“命名条件”以提高可读性，并说给变量赋布尔表达式突然使它成为类似于宏的动态条件时，我丢掉它。

---

编辑1 ：他们不会像宏一样明确地说出它（直接引号放在引号内），因为我们不会事先知道任何其他语言。

他们说的方式“变量存储未评估的条件”，就像 ，说这是一个宏，这是我的观点。他们暗示说它实际上等同于宏，而无需说“宏”。

---

以下是代码形式的声明：

x,y = 1,2
less = x < y 
more = x > y

'''
less/ more claimed to store not boolean True/False but some magical way of storing the
expression itself (unevaluated,say like a macro) and apparently 
'no value is being stored to less and more'. 
'''

它被表示为好像正在做的事情：

// C-style
#define less (x < y) 
#define more (x > y)

当然，这不是真的，因为所有存储在所谓的“命名条件”中的less和more只是x和{之间的运算符的返回值。 {1}}。

这很明显，因为根据正式的手册页和规范，y，<，>，==，<=都具有布尔返回值，以及>=或less仅存储more或True布尔返回值，我们可以通过在它们上调用False和/或通过调用来证明print()。

此外，更改x和y的值（例如执行type()不会更改x,y = y,x或less的值，因为它们不是存储动态表达式而是存储静态返回值初始more和>上的<或x操作数的值。

问题不是该声明是对所谓抽象的误解（它实际上不是抽象，在asm或C中也可以实现类似的存储），而是如何清晰有效地阐明 strong>对我的老师说，它不能像C宏那样工作，而是静态存储y或>的布尔返回值。

解决方法

很显然，less = x < y只是查看x和y的当前值，并将True或False存储到变量less中。

如果我了解您和您的老师的不同意见，那么您对以下代码将输出什么有不同的想法：

x,y = 1,2
less = x < y
print(less)
x,y = 2,1
print(less)

,

“宏”可以实现为可评估的文本字符串，例如（错误示例-不是推荐的解决方案）：

less = "({0}) < ({1})"

并像这样使用它们：

x = 1
y = 3
outcome = eval(less.format("x","y"))

但这确实是一件愚蠢的事情，eval()容易受到安全问题的影响。

也许您的老师打算使用lambda expressions，这是无名的临时功能：

less = lambda a,b: a < b
x = 1
y = 3
outcome = less(x,y)

注意： standard library operator module：lambda a,b: a < b中已有operator.lt的功能。