这并不是一个具体的问题, 我仅仅是对所见到的某些反常现象心存好奇, 并且想确认一下自己对于“is”运算符的理解是否正确无误。
这些都是可以被预料的解释性的输出内容。
>>> True是True。
True
表达式（1==1）的判断结果是逻辑真值True。
True
此时, 我们去进行一个操作, 这个操作的内容是为某个事物给它赋予属性, 而赋予的这个属性的名称是被称为True的。
>>> True = 'abc'
>>> True == 'abc'
True
返回结果是真的, 字符串内容是abc。
True
对于布尔运算这种情况, 解释器仍然会返回True这个值, 不过, 针对这个布尔运算所产生的最终结果, 人们将其认定为是既不属于abc范畴的, 同时也是不属于True范畴的。
>>> (1==1)
True
>>> (1==1) is 'abc'
这个说法不正确。
>>> (1==1) is True
False
谁能解释这个奇怪的行为？
令人感到诧异的是, True这个词并不是一个被保留的关键字, 或者说它也不是某种所有权的专属词汇。
现在是这样的, True这三个字母已经被指定成了编号是三的那个地方的关键字。然后那个赋值操作的这个行为呢, 它会引发一种错误状况。
大多数已经内置在了那个关键字当中……几乎您可以把所有的数值全都重新实施分配的行为。值得让人感到庆幸的是, 这些数值通常是局限在本地范围之内的, 所以当一个粗心的程序员在他的代码函数里面执行这种操作的时候, 那个行为它将保持在本地的局部区域里面, 而不会影响到其他地方。
@: 举个例子来说的话, id在里本来是一个内置函数, 可是大家经常把它重新赋值给某个对象的属性用, 比如在使用数据库对象关系映射工具ORM的时候就是这样。
考虑到那个内置的id()函数其实除了用来调试代码以外, 在其他的实际功能方面用处并不大, 所以呢, 我不太确信它能被称作是“毫不费力”这种说法。
当把这个东西作为对象的属性的时候呢, 在C语言里面, 你总是可以通过这种方式去访问它, 也就是用那种self后面跟着.id的办法, 或者说是在特定的名称空间里面用那个.id的方式来拿到它的值, 这个结论是确定的, 虽然我已经见过有人写过像是说对于那个id进行循环遍历并且中间没有指定具体源那样的代码了, 甚至我自己也写过这种让人看不懂类似的代码, 所以说从实际的操作层面来讲, 想要实现这样的效果是非常容易的。
就像这种情况在这里反复出现一样, 我发现我还没把问题输入完毕呢, 答案就已经找出来了。
这里有两个"True", 一个是布尔值, 另一个是名为True的变量。最开始的时候, 它们俩互相之间是相等的。
这就是为什么就算更改了名为True的这个变量以后, 像(1 == 1)这样的布尔运算依然能够返回True的原因, 因为它们最终返回的是那个布尔值True。不过, 这时候它们不等于字符串"True"变量的新值。
你大声地笑, 你自己都已经回答了那个问题了。
在那个时候, 我内心当中是特别喜欢的。
@JMK确实是这么回事, 我当时心里头琢磨的是, 伊玛这个人呀居然成了头一个回应这个问题的角色, 还带个笑脸的标识呢, 可遗憾的是, 我压根儿就没瞧见他的那段回答。
True基本上就等于1, 它带有一个挺奇怪的表示形式（repr函数）。 :-)。
True 并不是一个带有 repr() 方法的数字1。它是一个单例的内置值, 在某种特定情况下, 其大小恰好等于1。按照解释器的角度来看, 除了明显的晦涩难懂之外, 使用其他类似的单例值来执行如 if : print 3 这样的操作, 其实并没有任何错误之处。
从示例中可以明显地看出这一点, 例如省略号在无人使用的numpy数组中拥有完全不同的切片功能。这就证明我们绝对不能把单例的值当成1来对待。比如说, 拿True加上一和单纯的一来进行比较。
(True, int)
是名称空间引发了这一状况, 而这个名称空间则是被隐藏的交互式控制台给遮蔽住的。
一开始的时候, 您拥有的是个普通的True布尔值, 这个值是跟着某个模块一起过来的。
当我们重新对 True 这个变量进行定义的时候, 其实就是在当前的这一整个模块的范围内对它的含义进行了新的设定, 在这样的具体情景之下, 我们给它赋值的那个东西, 也就是它此刻所代表的那个默认的一个对象或者值而已。
因此, 您这边实际上有两个不同的对象, 第一个是 .True 这个对象, 第二个是 .True 这个对象。
In : ,
输入里面写着那个键是真正的状态, 然后它的值是一个不太好的主意。
在输入的内容里面, 确实是正确的状态。
输出的内容是'a bad idea'。
In : .True
Out: True
这部分内容解释了如何让它变得不可见, 不过假如你非要这么做的话, 也是可以执行.True = 4的, 从某种层面来看, 这样做并不能算是对最开始的那个问题做出一个完整的答案。
关于我在对原始问题中的代码内容进行分析并且试图阐明在代码当中具体所发生的情况这一方面，现正在予以说明。
我只是想表示那个东西更深一层嘛。您可以执行True等于4这种操作, 然后1加等号1这个判断表达式依然会返回True这个结果。哪怕是一些比内置对象还要底层的层面, 它们也是指向那个真实的客体, 或者说这些情况是由系统内核直接来进行处理的。
@: 好的, 我非常清楚你所表达的意图。
你需要在你自己所给出的那份答复里面再去增添一些更多的文字内容, 这些内容本来应该被写成那种补充说明性质的备注, 但是因为这个备注的篇幅非常之长, 以至于它不得不需要进行专门的格式化处理才好。
.7
...
>>>
>>> id(True)
>>> id(.True)
>>> True = 这个字符串是abc。
>>> id(True)
id中的值, 基本上, 就是对象的内部标识。或者换一种说法吧, 那就是它的真实名称。这话从字面上理解的意思是说, C指针已经变成了整数。is测试是用来比较对象身份的。
>>> 1==1
True
>>> id(1==1)
这意味着比较得到的布尔结果是“旧”的True, 而且还可以继续作为有效的True进行使用。
您把名称重新进行绑定操作, 这个表示True的意思是, 在解释器显示>>>这个提示符的地方, 当前所处的模块就是这里所指出的那个。
>>> True
'abc'
>>> .True
True
和：
>>>
>>> id(.True)
>>> .True
'abc'
>>>
对于正在起步阶段、作为新手去编写程序的人员, 在他们的代码工作里, 当这些人动手写出了像下面这样子的一个函数的时候, 经常就会遇见同样一种状况。
定义了一个叫做foo的函数, 这个函数的参数被命名为list。
...
list是一个系统内部自带的函数, 不过在函数foo这个具体的环境里面, 这个叫list的名称已经被重新绑定到了那个参数的身上, 所以, 在后面省略号所表示的那些内容里面的某个位置处, 使用者或执行者可能会突然发现自己感到有些意外和惊讶:
x = list(y)
在他们的那个意图里面, 他们希望这个动作去调用名叫.list的方法, 但是很遗憾呢, 它在实际操作的时候, 居然尝试着把自身的一个变量给当作成了一个函数来运行。
这种方式在理论上是可行的, 但是从软件设计的角度来看, 它往往不是一个理想的选择, 其核心问题在于开发者通常是为了通过特定的名称来直接调用或访问系统中的相关元素。
当然了, 系统也允许你为这些内部关联重新绑定新的名称, 不过从工程实践的角度评估, 这被认为是一个比原有做法更加糟糕、更加不可取的技术决策和改进方案, 这一点值得引起充分的重视:
