don't leak in id()

[davidhewitt]

The justification in id to leak seems completely baseless, as CPython indeed returns True in the case mentioned in the comment:

$ uvx python
Python 3.14.2 free-threading build (main, Dec  9 2025, 20:27:05) [Clang 21.1.4 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> id([]) == id([])
True

There is one test failure, for id([]) != id(()), the way to solve this IMO would be to make () a singleton like it is in CPython (which would be a performance win anyway).

[codspeed-hq]

Merging this PR will not alter performance

✅ 13 untouched benchmarks

---

_{Comparing dh/id-leak (10d36e5) with main (c75f160)}

[vibe-kanban-cloud]

Review Complete

Your review story is ready!

View Story

Comment !reviewfast on this PR to re-generate the story.

[samuelcolvin]

What happens to:

assert id([]) == id({})
# or even
assert id([]) == id((1,))

Is there a possibility that the same slot could get reused causing the same id for different values? I guess the same could be true for cpython.

I guess the one case we want to avoid is where python says id(X) != id(Y) and monty returns id(X) == id(Y) in some realistic scenario. If that's not possible, I'm fine with this.

[davidhewitt]

It's documented https://docs.python.org/3/library/functions.html#id

Two objects with non-overlapping lifetimes may have the same id() value.

... which is the case for all these tests. Whether they actually do is an implementation detail.

I feel that it's more correct to not leak than to attempt to match CPython implementation details here.

[davidhewitt]

Small tuple optimization in #90

[samuelcolvin]

okay, I'm good with this change.

But let's add those cases I asked about to tests with an explanation to make the behaviour explicit.

[davidhewitt]

These cases will fail until #90 is merged.