( s is "" ) 和 ( s == "" ) 在 Python 2.6.2 中可以给出不同的结果吗?

发布于 2024-09-08 03:35:09 字数 749 浏览 2 评论 0 原文

正如任何 Python 程序员都知道的那样,您应该使用 == 而不是 is 来比较两个字符串是否相等。然而,实际上是否存在 ( s is "" )( s == "" ) 在 Python 2.6.2 中给出不同结果的情况?

我最近在代码审查中遇到了使用 ( s is "" ) 的代码,在指出这是不正确的同时,我想举一个例子来说明这可能会失败。但尽我所能,我无法构造两个具有不同身份的空字符串。看来 Python 实现必须在许多常见操作中对空字符串进行特殊处理。例如:

>>> a = ""
>>> b = "abc"[ 2:2 ]
>>> c = ''.join( [] )
>>> d = re.match( '()', 'abc' ).group( 1 )
>>> e = a + b + c + d 
>>> a is b is c is d is e
True

但是,这个问题表明有 ( s is "" )( s == "" ) 可以不同的情况。谁能给我举个例子吗?

As any Python programmer knows, you should use == instead of is to compare two strings for equality. However, are there actually any cases where ( s is "" ) and ( s == "" ) will give different results in Python 2.6.2?

I recently came across code that used ( s is "" ) in code review, and while pointing out that this was incorrect I wanted to give an example of how this could fail. But try as I might, I can't construct two empty strings with different identities. It seems that the Python implementation must special-case the empty string in lots of common operations. For example:

>>> a = ""
>>> b = "abc"[ 2:2 ]
>>> c = ''.join( [] )
>>> d = re.match( '()', 'abc' ).group( 1 )
>>> e = a + b + c + d 
>>> a is b is c is d is e
True

However, this question suggests that there are cases where ( s is "" ) and ( s == "" ) can be different. Can anyone give me an example?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

彼岸花似海 2024-09-15 03:35:09

Python is 测试对象的同一性而不是相等性。下面是一个使用 is== 给出不同结果的示例:

>>> s=u""
>>> print s is ""
False
>>> print s==""
True

Python is tests the objects identity and not equality. Here is an example where using is and == gives a different result:

>>> s=u""
>>> print s is ""
False
>>> print s==""
True
时光暖心i 2024-09-15 03:35:09

正如其他人所说,不要依赖未定义的行为。但是,由于您要求提供 Python 2.6 的特定反例,所以它是:

>>> s = u"\xff".encode('ascii', 'ignore')
>>> s
''
>>> id(s)
10667744
>>> id("")
10666064
>>> s == ""
True
>>> s is ""
False
>>> type(s) is type("")
True

Python 2.6 唯一能以非正常空字符串结束的空字符串是当它执行字符串操作并且不确定时提前了解字符串的长度。因此,当您对字符串进行编码时,错误处理程序可能最终会剥离字符并在完成后修复缓冲区大小。当然,这是一个疏忽,在 Python 2.7 中可以轻松更改。

As everyone else has said, don't rely on undefined behaviour. However, since you asked for a specific counterexample for Python 2.6, here it is:

>>> s = u"\xff".encode('ascii', 'ignore')
>>> s
''
>>> id(s)
10667744
>>> id("")
10666064
>>> s == ""
True
>>> s is ""
False
>>> type(s) is type("")
True

The only time that Python 2.6 can end up with an empty string which is not the normal empty string is when it does a string operation and it isn't sure about in advance how long the string will be. So when you encode a string the error handler can end up stripping characters and fixes up the buffer size after it has completed. Of course that's an oversight and could easily change in Python 2.7.

一场信仰旅途 2024-09-15 03:35:09

你不应该关心。与被定义为单例的 None 不同,没有规则表明只有一个空字符串对象。因此, s is "" 的结果取决于实现,并且无论您能否找到示例,使用 is 都是不行的。

You shouldn't care. Unlike None which is defined to be a singleton, there is no rule that says there is only one empty string object. So the result of s is "" is implementation-dependent and using is is a NO-NO whether you can find an example or not.

丑疤怪 2024-09-15 03:35:09

它似乎适用于任何实际上是字符串的东西,但是看起来字符串的东西(例如unicode或str的子类或类似的东西)将会失败。

>>> class mysub(str):
    def __init__(self, *args, **kwargs):
        super(mysub, self).__init__(*args, **kwargs)

>>> 
>>> q = mysub("")
>>> q is ""
False
>>> q == ""
True

编辑

出于代码审查和修改的目的反馈 我认为这是不好的做法,因为它实现了意外的测试(即使我们忽略了类型匹配时它是否始终表现相同的不确定性)。

if x is ""

意味着 x 具有正确的值和类型,但没有显式的类型测试,这会警告未来的维护者或 api 用户等。

if x == ""

意味着 x 只是正确的值

It seems to work for anything which actually is a string, but something which just looks like a string (e.g. a unicode or subclass of str or something similar) will fail.

>>> class mysub(str):
    def __init__(self, *args, **kwargs):
        super(mysub, self).__init__(*args, **kwargs)

>>> 
>>> q = mysub("")
>>> q is ""
False
>>> q == ""
True

edit:

For the purposes of code review & feedback I would suggest that it was bad practice because it implements an unexpected test (even if we ignore the uncertainty of whether it will always behave the same when the types match).

if x is ""

Implies that x is of the correct value and type, but without an explicit test of type which would warn future maintainers or api users, etc.

if x == ""

Implies that x is just of the correct value

樱桃奶球 2024-09-15 03:35:09

您找不到示例,因为有些东西是唯一的且不可改变 - 因此 Python 将它们保留一次,因此 is 有效。其中包括 (), '',u'', True, False, None CPython 甚至保留了一些常用的数字,即 0, 0.0, 1, 1.0,

You can't find a example because some things are unique and not muteable - so Python keeps them around exactly once and therefore is works. These include (), '',u'', True, False, None CPython even keeps a few frequently used numbers, ie 0, 0.0, 1, 1.0,

笨死的猪 2024-09-15 03:35:09

可能不会,CPython 似乎在所有情况下都会优化 "" 的虚假实例。但正如其他人所说,不要依赖于此。

Probably no, CPython seems to optimize spurious instances of "" away in all cases. But as the others say, don't rely on that.

西瑶 2024-09-15 03:35:09

未定义的行为是一个模糊的问题。 Python 规范定义了一些内容,并且遵循的实现必须符合这些内容,并且还有一些内容可供选择。通过查看 Python 的源代码,您可能会确信这种行为永远不会发生在实际的字符串对象上(与显示的 unicode 与非 unicode 以及其他接近但不相关的示例不同)。很高兴,您将在代码中留下这样的测试。

但 Python 实现并不能保证它总是有效。未来的一些实现可能会导致它发生变化,并且您将遇到痛苦的不兼容性。

因此,经验法则很简单:不要这样做。仅将运算符用于其预期且有据可查的用途。不要依赖将来可能会发生很大变化的实现工件。

Undefined behavior is a murky issue. There are things the Python specification defines and adhering implementations must conform to, and there are things left to choice. You may get convinced, by looking into the source code of Python, that this behavior can never happen for actual string objects (unlike unicode vs. non-unicode and other close-but-irrelevant examples shown). Happy, you will leave such a test in a code.

But the Python implementation doesn't guarantee it will always work. Some future implementation may cause it to change and you'll have a painful incompatibility.

So the rule of thumb with this is simple: don't do it. Use operators only for their intended and well documented use. Don't rely on artifacts of implementation that may very well change in the future.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文