Question

好的，听我说这里;这并不像你想象的那样愚蠢。

首先，一些背景：我最近开始使用ctypes模块，作为技术测试，我想编写一个Mandelbrot资源管理器，使用pygame和ctypes分别进行事件处理和访问Mandelbrot计算dll。我最初的计划是通过让Mandelbrot函数计算并存储字符数组中整行像素的值并返回指向该数组的指针来最小化ctypes包装器开销：

Mandelbrot.restype = c_char_p
#...
str_location = Mandelbrot(x)
row = str_location.value

事实证明这并没有真正起作用。 value方法有两个缺点：它会降低性能，因为它将C字符串逐字节复制到python字符串中，并且它不知道字符串的预期长度，因此数据中的任何零都将被视为空终止符导致丢失任何进一步的数据。

我的第一个行动是将一个快速DLL混合在一起，允许我反汇编一些Python对象。它有以下两个功能：

#define DLLINFO extern "C" __declspec(dllexport)
DLLINFO char show_char(char *p)
{
    return *p;
}
DLLINFO void mov(char *p, char payload)
{
    *p = payload;
}

我还将show_char函数打包在Python函数show_object中，该函数使用sys.getsizeof来打印Python对象的内存内容。拆卸字符串显示了一个非常简单的设计：

>>> from hack import *; import sys
>>>
>>> #string experiment
>>> a = '01234567'
>>> hex(sys.getrefcount(a))
'0x3'
>>> hex(id(type(a)))
'0x1e1d81f8'
>>> hex(len(a))
'0x8'
>>> show_object(a)
  3  2  1  0 byte

  0  0  0  4   0    #reference count (+1 temporary reference)
 1e 1d 81 f8   4    #pointer to type
  0  0  0  8   8    #length
 94  b b6 98  12    #???
  0  0  0  1  16    #???
 33 32 31 30  20    #Data '0123' (little endian)
 37 36 35 34  24    #Data '4567'
           0  28    #Null terminator
>>> #sys.getsizeof reported 29 bytes for 9 bytes of data.

（之后添加的数据评论）

我尝试用可变的bytearray替换字符串，并且我反汇编了一个bytearray以查看我应该将Mandelbrot数据写入的位置：

>>> #bytearray experiment
>>> b = bytearray('01234567')
>>> hex(sys.getrefcount(b))
'0x2'
>>> hex(id(type(b)))
'0x1e1e5e20'
>>> hex(len(b))
'0x8'
>>> show_object(b)
  3  2  1  0 byte

  0  0  0  3   0    #reference count (+1 temporary reference)
 1e 1e 5e 20   4    #pointer to type
  0  0  0  8   8    #length
  0  0  0  0  12    #???
  0  0  0  9  16    #???
  2 3a 63 a0  20    #???
  2 92 93 38  24    #???
  2 91 e4 90  28    #???
           1  32    #???
>>> #sys.getsizeof reported 33 bytes for 8 bytes of data

好吧，我无法弄清楚数据在bytearray中的位置，所以没有骰子。

我的下一个计划是使用内置于ctypes的可变字符串create_string_buffer替换字符串。

>>> #buffer experiment
>>> from ctypes import *
>>> c = create_string_buffer('01234567')
>>> hex(id(type(c)))
'0x1ceb778'
>>> show_object(c)
  3  2  1  0 byte

  0  0  0  3   0    #reference count
  1 ce b7 78   4    #pointer to type
  2 38 f7 38   8    #???
  0  0  0  1  12    #Here be dragons
  0  0  0  0  16    #etc.
  0  0  0  9  20
  0  0  0  9  24
  0  0  0  0  28
  0  0  0  0  32
  0  0  0  0  36
 33 32 31 30  40    #data '0123'
 37 36 35 34  44    #data '4567'
  0  0  0  0  48
  0  0  0  0  52
  0  0  0  0  56
  0  0  0  0  60
  2 38 f8 40  64
  2 38 f7 a0  68
 ff ff ff fe  72
  0 2e  0 65  76
>>> #sys.getsizeof reported 80 bytes for 9 bytes of data.

嗯。至少数据存在于某处。不幸的是，这个对象太冗长而不实用。此外，它不是一个内置类型，所以我很难让它与其他功能一起工作。这时我决定切换回字符串并运行一些谨慎的测试来修改字符串：

>>> from hack import *
>>> s = "Hello, world!"
>>> show_object(s)
  3  2  1  0 byte

  0  0  0  3   0
 1e 1d 81 f8   4
  0  0  0  d   8
 8f 8d ce 9c  12
  0  0  0  0  16
 6c 6c 65 48  20
 77 20 2c 6f  24
 64 6c 72 6f  28
        0 21  32
>>> mov(id(s)+32, 63)
>>> print s
Hello, world?
>>> mov(id(s)+8,5)
>>> print s
Hello

到目前为止一切顺利。至少没有什么事情我这样做了几次。实际上，即使将长度修改为较低的值也不会立即引起任何问题。（我不打算那样做）那么，为什么我在列出显示字符串可变的数据后会问这个问题呢？

首先，我知道硬件可以将字符串标记为不可变，并且尝试修改它们可能会导致段错误或类似问题：

char good_string[80];
good_string[8] = '!'; //Everything's okay so far.
char* bad_string = "This string's made out of const chars, beware!";
bad_string[8] = '!'; //And now you've got segfault!

其次，更重要的是，我对Python的内部工作方式知之甚少，无法绕过Python对字符串的锁定和使用未定义的行为进行操作。现在，我很容易让自己相信Python FAQ声明字符串不变性的原因是错误的（我没有改变字符串的大小和字符串不是像整数一样的元素。），但我不知道是否有一些隐藏的原因字符串不应该被修改，如果我尝试做我打算做的事情，某些东西会在我脸上爆炸。这是我提交这个问题的主要原因;我希望有更多知识的人会关心我。

非常感谢，您阅读了整个问题。对不起，简洁不是我的强项。：）

Answer 1

有些计算机系统可以在硬件级别将任意范围的内存标记为只读，但这不是python中发生的事情。发生的事情是，根据定义，python可以防止在创建的位置更改字符串。

是的 - 通过更改python代码或提供新的内置函数来编写允许字符串在某些情况下可变的代码是完全可能的，但如果你试图使用你的mutable就会遇到真正的困难例如，字符串作为字典键，并清楚地给出字符串的存储方式，改变长度将是艰难的（如果不是不可能在大多数情况下 - 你需要在当前字符串之后立即释放空闲内存以便扩展到例如）。 / p>

请记住，即使使用可能称为直接内存访问的语言（例如C），它的字符串在某些情况下也是可变的：您可以更改特定字符，但是您可以＆＃39;无需预先为它预留内存，或者在每次更改时更改它的标识（如果你有多个引用就会出现问题），可以延长C字符串的长度。

python字符串在硬件级别上实际上是不可变的吗？

1 个答案: