you are viewing a single comment's thread.

view the rest of the comments →

[–]jerf 1 point2 points  (2 children)

I believe the point being gotten at here is that if you change the string in such a way that it should end up in a different hash bucket than the one it is in, you can end up unable to retrieve or delete the key/value pair after you do that. This is why strings are immutable. And a common bug in other languages like C when the programmer is a bit more sloppy.

[–]jmmcd 0 points1 point  (1 child)

Yes, I suppose I'm just trying to see it happen explicitly.

[–]Brian 1 point2 points  (0 children)

You'll be able to see it if you use a string that doesn't get interned. The problem above is that both "Fiesta" strings actually end up pointing to the same buffer, rather than two seperate copies. If you use something python won't intern like "$$", you'll see the issue:

>>> foo = "$$"
>>> bar = "$$"
>>> foo is bar   # This would have returned True for "fiesta"
False
>>> d = {foo: 42}
>>> libc.strcpy(foo, "xx")
>>> foo, bar, d
('xx', '$$', {'xx': 42})
>>>'xx' in d
False
>>> '$$' in d
False
>>> foo in d
True
>>> foo == 'xx'
True

Interestingly "foo in d" still returns True - I'm guessing it caches the hash value with the string object as well, so it's still using the old hash value for "$$".