Introduction

If you want the real source of Python’s hash behavior, the first place to look is the CPython source tree, not a blog post. The exact algorithm depends on the object type, and for strings and bytes the modern implementation is tied to hash-randomization and SipHash-style security decisions rather than to one simple universal formula.

There Is No Single Hash Function for Every Object

Python’s built-in hash() delegates to type-specific implementations.

Examples:

• integers have one hashing path
• tuples combine the hashes of their elements
• strings and bytes use a dedicated string/bytes hash implementation
• user-defined objects inherit identity-based behavior unless they override __hash__

So the right answer to “where is Python’s hash algorithm” is often “which object type are you asking about?”

Where to Look in the CPython Source

For CPython, useful source locations include:

• 'Python/pyhash.c'
• 'Include/cpython/pyhash.h'
• type-specific files such as Objects/longobject.c and Objects/tupleobject.c

The generic built-in hash() behavior is connected to those lower-level implementations through the object type machinery.

If you are reading source, the path for integers is different from the path for strings, and tuples add another composition layer on top.

Strings and Hash Randomization

For text-like objects, Python hash behavior changed over time for security reasons. Older descriptions on the internet often mention older algorithms such as FNV variants, but modern CPython documentation and PEP discussion point you toward the SipHash-based design introduced to resist collision attacks better.

That is why two important practical facts matter:

• string hashes are implementation-specific
• string hashes are salted, so they may vary between interpreter runs

Simple demonstration:

print(hash("example"))

If you run that in separate interpreter processes, the result may differ depending on the environment and hash randomization settings.

Type-Level Example in Python

You can see how type-specific hashing works by defining a custom class.

1class Point:
2    def __init__(self, x, y):
3        self.x = x
4        self.y = y
5
6    def __eq__(self, other):
7        return isinstance(other, Point) and self.x == other.x and self.y == other.y
8
9    def __hash__(self):
10        return hash((self.x, self.y))
11
12p = Point(1, 2)
13print(hash(p))

This example relies on tuple hashing, which in turn relies on the hashes of the tuple elements.

That makes a nice mental model for Python hashing in general: many objects do not invent a standalone algorithm from scratch; they compose existing hash behavior according to the object’s structure.

What If You Want the Exact Algorithm?

If you need the exact current algorithm for a particular CPython version, you should read the source and relevant Python Enhancement Proposal material together.

For string and bytes hashing, PEP 456 is especially relevant because it explains why Python moved toward SipHash and how the security reasoning shaped the design.

For integers, tuples, and custom objects, the source files are usually more direct than prose documentation.

A Practical Warning

Do not design persistence, networking, or cross-language interoperability around Python’s raw hash() output.

Reasons include:

• it is not guaranteed stable across versions or implementations
• string hashes may vary across interpreter runs
• other Python implementations do not have to match CPython exactly

If you need stable hashing, use a dedicated algorithm from hashlib or another explicit hashing library.

Example:

1import hashlib
2
3value = "example".encode("utf-8")
4print(hashlib.sha256(value).hexdigest())

That is the right choice for reproducible external behavior.

Common Pitfalls

The most common mistake is assuming Python has one universal hash algorithm for all object types. It does not.

Another issue is reading old posts that describe pre-SipHash string hashing as though it still explained current CPython behavior.

People also treat hash() as stable across runs and versions. That is unsafe, especially for strings and bytes.

Finally, do not confuse CPython internals with the Python language specification. The language exposes hash(), but many exact algorithm details are implementation choices.

Summary

• Python’s hash() behavior is type-specific rather than one single algorithm.
• For CPython source, start with Python/pyhash.c, pyhash.h, and type-specific object files.
• Modern string and bytes hashing is tied to SipHash-style security and hash randomization.
• Exact details depend on the CPython version and object type.
• Use explicit stable hashes from hashlib when reproducibility matters outside one interpreter process.