Новые экземпляры локальной функции создаются каждый раз, когда вызывающая функция называется? [Дубликат]

Если вы прочитали документацию для id , в ней говорится:

Вернуть «идентификатор» объекта. Это целое число, которое гарантировано будет уникальным и постоянным для этого объекта в течение его жизни. Два объекта с неперекрывающимися временами жизни могут иметь одинаковое значение id().

И это именно то, что происходит: у вас есть два объекта с неперекрывающимися сроками службы, потому что первый из них уже вышел

---

Но не верьте, что это будет всегда . Особенно, если вам нужно иметь дело с другими реализациями Python или с более сложными классами. Все, что говорит язык, состоит в том, что эти два объекта могут иметь одинаковое значение id(), а не то, что они будут . И тот факт, что они делают , зависит от двух деталей реализации:

• Сборщик мусора должен очистить первый объект, прежде чем ваш код даже начнет выделять второй объект- который, как гарантируется, произойдет с CPython или любой другой реализацией пересчета (когда нет круговых ссылок), но довольно маловероятен с коллективным сборщиком мусора, как в Jython или IronPython.
• Распределитель под крышками имеет чтобы иметь очень сильное предпочтение повторного использования недавно освобожденных объектов того же типа. Это справедливо в CPython, который имеет несколько уровней фантастических распределителей поверх базового C malloc, но большинство других реализаций намного больше уходят в основную виртуальную машину.

---

Последнее: факт, что object.__repr__ имеет подстроку, которая оказывается такой же, как id как шестнадцатеричное число, является всего лишь артефактом реализации CPython, который нигде не гарантируется. Согласно docs :

Если это вообще возможно, это должно выглядеть как действительное выражение Python, которое может быть использовано для воссоздания объекта с тем же значением (с учетом соответствующая среда). Если это невозможно, должна быть возвращена строка формы <...some useful description…>.

Тот факт, что CPython object, кажется, помещает hex(id(self)) (фактически, я считаю, что он делает эквивалент sprintf, указав его указатель на %p, но поскольку CPython id просто возвращает тот же самый указатель, который был добавлен к long, который заканчивается тем же самым) нигде не гарантируется. Даже если это было верно, так как ... до object даже существовало в начале 2.x дней. Вы можете полагаться на него для такого простого простого «что здесь происходит» отладки в интерактивном приглашении, но не пытайтесь использовать его за его пределами.

Пример, когда место памяти (и id) не освобождено:

print([someClass() for i in range(10)])

Теперь идентификаторы уникальны.

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

Я чувствую здесь более глубокую проблему. Вы не должны полагаться на id, чтобы отслеживать уникальные экземпляры на протяжении всей вашей программы. Вы должны просто увидеть его как не гарантированный индикатор местоположения памяти в течение всего экземпляра объекта. Если вы сразу создаете и освобождаете экземпляры, вы можете очень хорошо создавать последовательные экземпляры в том же месте памяти.

Возможно, вам нужно отслеживать статический счетчик класса, который присваивает каждому новому экземпляру уникальный идентификатор, и увеличивает статический счетчик класса для следующего экземпляра.

Попробуйте это, попробуйте вызвать следующее:

a = someClass()
for i in range(0,44):
    print(someClass())
print(a)

Вы увидите что-то другое. Зачем? Причина того, что память, выпущенная первым объектом в цикле «foo», была повторно использована. С другой стороны, a не используется повторно, поскольку сохраняется.