You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
C API: Remove deprecated PyBytesObject.ob_shash member, or remove the deprecation #158074
@methane deprecated PyBytesObject.ob_shash member in Python 3.11 with commit 2d8b764 and the instruction: "Use PyObject_Hash() instead."
We are now at Python 3.16, 5 releases later. So should we remove PyBytesObject.ob_shash member? Or should we keep it just remove the deprecation and keep the member (forever)?
When I added this warning, code objects held a large number of bytes objects, several of which were in very hot memory. In addition to overall memory usage, having ob_shash at the beginning of hot memory blocks likely impacted cache efficiency as well.
Currently, this issue has been resolved, and there is no strong reason to remove ob_shash. The reason we haven't removed the deprecation is that reducing direct access to the internals of Python object structs is good practice, and there is no need to encourage third parties to use this member again.
Looks like if you were to remove ob_shash, hash(b) would no longer be cached. This slows down dict access with bytes keys. Is that what you are proposing?
Yes, but note that dict entries already store the hash value, so recomputing the hash only becomes an issue when looking up the exact same bytes object multiple times.
When I originally added the warning/deprecation, the idea was that compacting hot, short bytes objects (like bytecode in code objects) by removing ob_shash would improve cache locality and offset the minor performance overhead of occasional hash recomputations. Remaining benefit was simply reducing the overall memory footprint.
Activity
methane commentedon Sep 24, 2026
When I added this warning, code objects held a large number of bytes objects, several of which were in very hot memory. In addition to overall memory usage, having
ob_shashat the beginning of hot memory blocks likely impacted cache efficiency as well.ref: #91020
gvanrossum commentedon Sep 24, 2026
Looks like if you were to remove ob_shash, hash(b) would no longer be cached. This slows down dict access with bytes keys. Is that what you are proposing?
methane commentedon Sep 24, 2026
Yes, but note that dict entries already store the hash value, so recomputing the hash only becomes an issue when looking up the exact same
bytesobject multiple times.When I originally added the warning/deprecation, the idea was that compacting hot, short
bytesobjects (like bytecode in code objects) by removingob_shashwould improve cache locality and offset the minor performance overhead of occasional hash recomputations. Remaining benefit was simply reducing the overall memory footprint.