Почему равенство верно?

Question

[Boris19]

Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> s = "test_string"
>>> id(s[1:5]) == id(s[2:6])
True

Comments

[Max Payne]

Потому что сравнивание id.

[Boris19]

Max Payne, почему id равны?

[longclaps]

Надо же, не сталкивался. Отличный вопрос.
Потыкав, обнаружил и такое:

s, t = "test_string", "dfgsdfgdfgds"
print(id(s[2:6]), id(t[2:6])) # True

Предположу, дело в том, что питон кэширует небольшие слайсы (как операторы) так же, как небольшие целые числа,
т.е. 2 слайса равной длины указывают на один объект.
Как только вы присвоите эти значения переменным, магия пропадёт.

[Boris19]

Pavel Denisov, тоже думал про переиспользование выделенной памяти, но тогда почему

>>> s = "test_string"
>>> id(s[1:5]) == id(s[2:4])
True

>>> s = "test_string"
>>> id(s[1:5]) == id(s[2:3])
False

[qlkvg]

Boris19, с последним все проще. слайс s[2:3] - это 's', такой объект, если я правильно понимаю, создается при запуске интерпретатора для оптимизации памяти. такое точно применяется для чисел до 127. https://mail.python.org/pipermail/python-dev/2008-... - в этом мэйллисте люди задаются примерно тем же вопросом, что в топике. но внятной инфы я там не нашел, только догадки

[SagePtr]

Из документации по функции id

Return the “identity” of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value.

Вся соль тут в "non-overlaping lifetimes". Так как s[1:5] после взятия id больше не нужна, то объект уничтожается, а следующий s[2:6] видимо создаётся уже на месте его, поэтому id и равны

[Boris19]

qlkvg, да, точно, проверил по исходникам питона, вы правы по поводу чисел. Только не до 127, а до 257.
Для одиночных ascii символов можно было бы предположить, что они внутри питона интерпретируются как указатель на эти числа, т.е. объект одиночного символа мог бы быть дочерним от объекта integer, с переопределением метода отображения __str__. Но не все одиночные символы ведут себя так, например:

>>> id('$')
42048688L
>>> id('$')
42047688L

Но с алфавитом действительно так:

>>> id('z')
41318920L
>>> id('z')
41318920L

Или покажите мне в исходниках, где эта магия по созданию объектов символов происходит, не смог найти

[qlkvg]

SagePtr, тоже об этом сразу подумал, но

>>> s = "test_string"
>>> id(s[1:5]) == id(s[2:6])
True
>>> id(s[1:5]) 
140592115145056
>>> id(s[2:6])
140592115145112
>>>

Шаманство какое-то. Хотя может из-за атомарности первой операции там применяется оптимизация, а во втором случае нет.

[Boris19]

SagePtr, тогда объясните почему

>>> s = "test_string"
>>> id(s[1:5]) == id(s[2:3])
False

[SagePtr]

Boris19, видимо, в этом случае питон создал второй объект уже в другом месте. Может быть, посчитал, что раз у них разные размеры, то лучше новый создать, а не переиспользовать старый

[Boris19]

SagePtr,

Может быть, посчитал, что раз у них разные размеры, то лучше новый создать, а не переиспользовать старый

Вот здесь тоже размеры разные:

>>> id(s[1:5]) == id(s[2:4])
True

[SagePtr]

Boris19, тогда исходники Питона в руки и смотрите, где и как происходит выделение памяти и почему в разных случаях по-разному.
Но вообще - на адреса памяти никогда не следует полагаться, что они будут те или иные, они могут быть в общем-то довольно произвольными, полагаться можно только на то, что если объект жив - он будет доступен по тому адресу, где он лежит (но только на этот момент исполнения программы, в следующий раз он может быть другим, а может быть и таким же, а если объект сдох - то тот же адрес может впоследствии быть назначен другому объекту, а может больше и не быть никому назначен и там будет лежать "труп" старого объекта)

[Boris19]

SagePtr, та это понятно, никто и не полагается на адреса, просто хотелось разобраться что к чему

[longclaps]

на адреса памяти никогда не следует полагаться

SagePtr, ну почему же - оператор is именно для этого создан.

[SagePtr]

longclaps, я имею ввиду, не стоит вручную резолвить адреса объектов и каким-нибудь образом полагаться на них, например, сравнивать их. В случае с оператором is то понятное дело, что объекты по обе стороны живы на время его вызова

Answer 1

[Александр Глухов]

Как говорится в официальной документации к версии языка 2.7:
https://docs.python.org/2/library/functions.html?h...

два объекта с непересекающимся временем жизни могут иметь одинаковый id

agluhov@forge:~$ python 
Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34) 
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = 'test_string'
>>> id(s[1:5]) == id(s[2:6])
True
>>> id(s[1:5])
139620785926528
>>> id(s[2:6])
139620785926528
>>> print(id(s[1:5]))
139620785926384
>>> print(id(s[2:6]))
139620785926576
>>> print(id(s[1:5]), id(s[2:6]))
(139620785926528, 139620785926528)

Это просто идентификатор, который является уникальным для каждого объекта в памяти на момент времени. Логично предположить, что интерпретатор отдает тот же буфер под слайс после того, как первый вызов функции отработал.

Comments

[Boris19]

А как же

>>> s = "test_string"
>>> id(s[1:5]) == id(s[2:3])
False
>>> print(id(s[1:5]), id(s[2:3]))
(43685728L, 19311272L)

или

>>> print(id(s[1:5]), id(s[2:8]))
(43685648L, 43685648L)

Тут же размер буфера под второй слайс должен быть больше чем буфер под первый слайс?

[Деревянко Александр]

Короче, чистый си рулит. Питон как всегда - вокруг да около ))) а конкретики нет ;)