А как проверить экземпляры объектов на абсолютную идентичность?

is

cmp() по спискам.

Одинаковые, в смысле это один и тот же объект? Тогда можно сравнить по id(x)==id(y)

id(x)==id(y)

Ух ты, у каждого экземпляра есть свой уникальный id?

У всех объектов есть свой id. По сути это адрес в памяти.

По полям проверять не вариант - они могут бытьи не заполнены.

Что значит не заполнены? Там None? Ну тогда None тоже можно проверять.

Если тебе нужно убедиться что там «абсолютно идентичные» объекты то используй is. Однако, может быть такое что объекты разные, но предоставляют одни и те же данные:

In [1]: x=1000

In [2]: y=1000

In [3]: x is y
Out[3]: False

Поэтому я бы использовал == для сравнения. Более подробно про это можно прочитать в описании метода __cmp__

Поэтому я бы использовал == для сравнения. Более подробно про это можно прочитать в описании метода __cmp__

Ок, спасибо, почитаю. Но мне и варианта moon хватило :)

дык is это и есть сравнение по id, ЕМНИП

Стандартная Жаба-ловушка. Из-за нее отказываться от is не стоит.

Почему в данном случае ты рекомендуешь is? В общем случае он же найдёт меньше совпадений.

PS лично я зарёкся этим is пользоваться.

Ну, кроме случая аля x is None.

Почему в данном случае ты рекомендуешь is?

В каком «данном» - для целых чисел? Не рекомендую. Но is - это единственный способ установить, что два имени ссылаются на один объект, что и нужно ТС.

OMG. У вас в пистоне даже целые, влазящие в регистры, боксятся что ли?

А ты не знал? Добро пожаловать же!

Мда, хреновенько питонистам. Одно радует, что питон простенький и немногословный

Одно радует, что питон простенький и немногословный

Да, этого у него не отнимешь.

In [1]: a = 10

In [2]: b = 10

In [3]: a is b
Out[3]: True

А если a = 1000 и b = 1000 то это на самом деле разные объекты.

Я тоже думал привести этот пример и проверил его на небольших числах — к удивлению обнаружил False (проверял в ipython). Но, помня, что первые n чисел типа кэшируются я выбрал числа побольше.

Сейчас у меня этот глюк не воспроизводится. Я поэтому пока склонен считать что я что-то попутал.

https://docs.python.org/2/c-api/int.html

Реально ты какой-то питонячий карго-культист, нет чтобы погуглить спокойно, документацию полистать.

может интересным будет

Кому надо — тот посмотрит, главное что задал направление и привёл корректный пример демонстрирующий проблемы. Заучиванием манов наизусть тоже не страдаю. Я на форуме отдыхаю, мне не всегда интересно копать слишком глубоко или искать справочную информацию. Я даже, о ужас, бываю не прав или невнимательно читаю топик.

Это помимо того что речь шла не о конкретном диапазоне чисел которые закэшированы (к слову, я знаю где и как это сделано), а о том что по каким-то причинам это _не_сработало_. Вот в этом направлении тебе надо было гуглить (а не тыкать в стандартный ман), тогда наткнулся бы, например, на http://stackoverflow.com/questions/15171695/weird-integer-cache-inside-python... . Но у меня было открыто окошко с третьим питоном, а не вторым. Можешь поломать голову как у меня получилось воспроизвести проблему. мне это не интересно т.к. кода который зависит от поведения оператора is я не пишу.

Но это всё фигня. Ты мне лучше скажи зачем ты ко мне прицепился? У тебя какой-то пунктик или мои посты задевают твою самооценку?

Это не стандартный ман, это _детали реализации_ cpython. Ты даже этого не понимаешь?

зачем ты ко мне прицепился

Я хотел уже зажечь третью звезду, а какие-то тупорылые вахтёры мне по надуманным причинам вторую гасят. По-этому когда я вижу от них тупняк, я считаю необходимым показать это всем.