如果Python字符串是不可变的，为什么如果我使用＆＃x2B; =将其保留相同的ID？

发布于 2025-02-06 04:08:37 字数 627 浏览 2 评论 0 原文

Python中的字符串是不变的，这意味着该值无法更改。但是，在以下示例中附加到字符串时，看起来原始字符串内存已修改，因为ID保持不变：

>>> s = 'String'
>>> for i in range(5, 0, -1):
...     s += str(i)
...     print(f"{s:<11} stored at {id(s)}")
... 
String5     stored at 139841228476848
String54    stored at 139841228476848
String543   stored at 139841228476848
String5432  stored at 139841228476848
String54321 stored at 139841228476848

相反，在下面的示例中，ID更改：

>>> a = "hello"
>>> id(a)
139841228475760
>>> a = "b" + a[1:]
>>> print(a)
bello
>>> id(a)
139841228475312

原文

Strings in Python are immutable, which means the value cannot be changed. However, when appending to the string in the following example, it looks like the original string memory is modified since the id remains the same:

>>> s = 'String'
>>> for i in range(5, 0, -1):
...     s += str(i)
...     print(f"{s:<11} stored at {id(s)}")
... 
String5     stored at 139841228476848
String54    stored at 139841228476848
String543   stored at 139841228476848
String5432  stored at 139841228476848
String54321 stored at 139841228476848

Conversely, in the following example, the id changes:

>>> a = "hello"
>>> id(a)
139841228475760
>>> a = "b" + a[1:]
>>> print(a)
bello
>>> id(a)
139841228475312

分享到QQ

分享到微博

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

发布评论

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

无尽的现实 2025-02-13 04:08:37

对于 str 恰好没有其他生活参考的情况，这是对CPYTHON特定的优化。在这种情况下，解释器“作弊”，允许其通过重新定位（可以放置，具体取决于堆布局）并直接附加数据来修改现有字符串，并经常在反复加压的环中大大降低工作（使其成为它）行为更像是摊销 o（1）附加 list 而不是 o（n）每次复制操作）。除了不变的 id 之外，它没有明显的效果在逻辑上被替换）。

您实际上不应该依靠它（非参考计算口译员无法使用此技巧，因为他们不知道 str 是否具有其他参考），per pep8的第一个编程建议：

代码应以不利的方式编写python的其他实现（Pypy，Jython，Ironpython，Cython，Psyco等）。

例如，不依赖Cpython的有效实现，以 a + = b 或 a = a = a + b 中的语句中的语句中的语句。即使在CPYTHON中，这种优化也很脆弱（仅适用于某些类型），并且在不使用重新计算的实现中根本不存在。在库的性能敏感部分中，应改用''。join（）表单。这将确保串联在各种实现的线性时间内发生。

如果您想打破优化，则有多种方法可以这样做，例如，将代码更改为：

>>> while i!=0:
...     s_alias = s  # Gonna save off an alias here
...     s += str(i)
...     print(s + " stored at " + str(id(s)))
...     i -= 1
...

通过创建别名，增加参考计数并告诉Python，将更改可见于以外的某个地方可见。 s ，因此无法应用它。同样，代码类似：

s = s + a + b

无法使用它，因为 s + a 首先发生，并且必须添加 b 的临时性，而不是立即替换 s ，优化太脆了，无法尝试处理。几乎相同的代码如：

s += a + b

或：

s = s + (a + b)

通过确保最终串联始终是 s 是左操作数，并且结果用于立即替换 s 来恢复优化。

It's a CPython-specific optimization for the case when the str being appended to happens to have no other living references. The interpreter "cheats" in this case, allowing it to modify the existing string by reallocating (which can be in place, depending on heap layout) and appending the data directly, and often reducing the work significantly in loops that repeatedly concatenate (making it behave more like the amortized O(1) appends of a list rather than O(n) copy operations each time). It has no visible effect besides the unchanged id, so it's legal to do this (no one with an existing reference to a str ever sees it change unless the str was logically being replaced).

You're not actually supposed to rely on it (non-reference counted interpreters can't use this trick, since they can't know if the str has other references), per PEP8's very first programming recommendation:

Code should be written in a way that does not disadvantage other implementations of Python (PyPy, Jython, IronPython, Cython, Psyco, and such).

For example, do not rely on CPython’s efficient implementation of in-place string concatenation for statements in the form a += b or a = a + b. This optimization is fragile even in CPython (it only works for some types) and isn’t present at all in implementations that don’t use refcounting. In performance sensitive parts of the library, the ''.join() form should be used instead. This will ensure that concatenation occurs in linear time across various implementations.

If you want to break the optimization, there are all sorts of ways to do so, e.g. changing your code to:

>>> while i!=0:
...     s_alias = s  # Gonna save off an alias here
...     s += str(i)
...     print(s + " stored at " + str(id(s)))
...     i -= 1
...

breaks it by creating an alias, increasing the reference count and telling Python that the change would be visible somewhere other than s, so it can't apply it. Similarly, code like:

s = s + a + b

can't use it, because s + a occurs first, and produces a temporary that b must then be added to, rather than immediately replacing s, and the optimization is too brittle to try to handle that. Almost identical code like:

s += a + b

or:

s = s + (a + b)

restores the optimization by ensuring the final concatenation is always one where s is the left operand and the result is used to immediately replace s.