gh-131525: Remove _HashedSeq wrapper from lru_cache

[lgeiger]

As suggested in #131525 (comment) this PR removes _HashedSeq wrapper from the Python-only functools.lru_cache implementation. Since tuple hashes are now cached (#131529) this wrapper is not needed anymore.

I ran some very quick benchmarks with the following ipython script to check whether this change has an impact on the performance:

from functools import lru_cache

@lru_cache(maxsize=1)
def foo(a, b, c, d, e):
    pass

%%timeit
foo(1, 2, 3, 4, 5)
foo(1, 2, 3, 4, 6)

In this toy benchmark with trivial hashes this change removes some overhead

version	pre #131529	main
C implementation	137 ns ± 2.51 ns	139 ns ± 0.682 ns
Python only	1.23 μs ± 35.2 ns	1.23 μs ± 6.91 ns
Python only no _HashedSeq (this PR)	788 ns ± 2.49 ns	777 ns ± 5.12 ns

In an example where hashes are artificially slow this change would've caused a regression before #131529 but now performs equally well (4.14 s without tuple hash cashing vs 1.03 s with hash caching).

class SlowInt:
    def __init__(self, val) -> None:
        self.val = val

    def __hash__(self):
        time.sleep(0.1)
        return hash(self.val)

%%timeit
foo(SlowInt(1), SlowInt(2), SlowInt(3), SlowInt(4), SlowInt(5))
foo(SlowInt(1), SlowInt(2), SlowInt(3), SlowInt(4), SlowInt(6))

I don't think a news entry is necessary since this only affects the Python only implementation, but let me know if I should still add one.

• Issue: Caching the tuple hash calculation speeds up some code significantly #131525

[lgeiger]

This value was never used

[rhettinger]

This line needs to be restored. Its job is to hold on to the object reference until the function returns (after the cache is in a stable state).

[lgeiger]

Good catch! Sorry about that, I wasn't aware. My IDE complained about it and I should've doubted it more. I reverted 5ebba28