Hi, I’m Nishant Vibhute
a Full Stack Developer. Software Architect. Mentor. Freelancer.

How Python’s id() Reveals What’s Really Happening in Memory

If you’ve ever printed id(obj) while debugging and wondered, “What exactly is this number?”, this post is for you. We’ll unpack how objects live in memory, what id() returns, and how it helps you reason about Python behavior—without getting lost in jargon.

• id(obj) returns a unique identity for the object during its lifetime.
• In CPython (the default Python), this is the memory address where the object’s header lives.
• Same id ⇒ same object (same memory). Same value does not imply same id.
• Immutable types (like small ints, some strings) may share objects due to caching/interning.

What exactly is returned by id()?

• In CPython, id(obj) is the address in RAM of the object’s header (technically, a pointer cast to an integer).
• In other Python implementations (e.g., PyPy), id() is still a unique identifier, but not guaranteed to be a raw memory address.

x = 42
print(id(x))        # e.g., 140709568352400
print(hex(id(x)))   # e.g., 0x7ffef9a8b2a0 (hex address form)

Think of id() like the flat number of an apartment. The furniture (data) can be identical in two apartments, but their flat numbers (ids) differ.

How objects are stored in memory (CPython view)

Every Python object has a C-level header with (simplified):

• Reference count (ob_refcnt) – how many active references point to it
• Type pointer (ob_type) – tells Python what kind of object it is (int, list, str, …)

So when you do:

x = 10

Python allocates (or reuses) an integer object and x holds a reference to it.
id(x) is the address of that object’s header.

Equality vs Identity: == vs is

• == checks value equality (same content)
• is checks identity (same object in memory)

a = [1, 2, 3]
b = [1, 2, 3]
c = a

print(a == b)   # True  (same contents)
print(a is b)   # False (different lists)
print(a is c)   # True  (same list object)

You can confirm with id():

print(id(a), id(b), id(c))
# a and c share the same id; b has a different id

Small integer caching & string interning

Python performs some clever optimizations.

Small integer caching (CPython)

• Integers in the range [-5, 256] are pre-allocated and reused.
• So two variables pointing to the number 10 often share the same object.

x = 10
y = 10
print(x is y)       # True in CPython
print(id(x) == id(y))  # True

Larger integers may or may not be reused depending on the code path:

x = 10_000
y = 10_000
print(x is y)  # Often False; depends on the runtime and context

String interning

• Short, identifier-like strings (e.g., 'hello', 'abc123') are often interned (reused).
• Dynamically created strings may not be interned unless you use sys.intern().

s1 = "hello_world"
s2 = "hello_world"
print(s1 is s2)  # Often True (interned)

s3 = "".join(["hello", "_world"])
print(s3 is s2)  # Often False (built at runtime)

Mutable vs immutable: why id() behaves differently

• Immutable objects (ints, strs, tuples) can be shared safely; Python may reuse them.
• Mutable objects (lists, dicts, sets) are distinct by default when created anew.

a = [1, 2]
b = [1, 2]
print(id(a) == id(b))  # False (two separate lists)

c = a
print(id(a) == id(c))  # True (aliasing the same list)

To make a copy (different id), don’t alias:

a = [1, 2, 3]
b = a.copy()      # or b = list(a) or b = a[:]
print(a is b)     # False

Can id() be reused?

Yes—after an object is destroyed, Python may allocate a new object at the same memory address (hence the same id later). This is why id() is only guaranteed to be unique during the object’s lifetime.

def demo():
    x = 999999
    print("inside:", id(x))
demo()

y = 999999
print("outside:", id(y))
# The numbers may or may not match depending on reuse; don’t rely on it.

Practical debugging uses

1. Check aliasing (shared references)
   “Are these two variables pointing to the same object?” a = {'count': 1} b = a print(a is b) # True
2. Spot unintended mutations
   If you expected a copy but see the same id, you’re mutating the original object.
3. Understand performance quirks
   Seeing identical ids for small ints/strings? That’s caching/interning, not a bug.

Real-life mental model

• Apartment (object) has a flat number (id) and furniture (value).
• Two apartments can look the same inside (equal contents), but the flat numbers differ.
• Two keys to the same apartment = multiple variables referencing one object.

Code you can run to “see” memory identities

def show(label, obj):
    print(f"{label}: value={obj!r} id={hex(id(obj))}")

# Small ints (often same id due to caching)
x, y = 10, 10
show("x", x)
show("y", y)

# Larger ints (may not share id)
p, q = 10_000, 10_000
show("p", p)
show("q", q)

# Lists: distinct objects
a, b = [1, 2, 3], [1, 2, 3]
show("a", a)
show("b", b)
print("a is b:", a is b)

# Aliasing
c = a
show("c (alias of a)", c)
print("a is c:", a is c)

Common pitfalls to avoid

• Don’t use is for value comparison. Use == for content and is for identity.
• Don’t rely on id() for ordering or persistence—it’s an implementation detail.
• Don’t assume id() is always a memory address outside CPython (e.g., PyPy).

Key takeaways

• id() is your window into object identity—great for debugging references.
• Same id ⇒ same object. Same value does not imply same id.
• CPython may reuse objects (small ints, interned strings); mutable containers are usually distinct unless explicitly aliased.

FAQ

Q: Why do two variables with 10 have the same id?
Because CPython caches small integers. It’s an optimization.

Q: Why does a is b sometimes return True for strings?
They may be interned (reused). It’s normal for short, identifier-like strings.

Q: Can I treat id() as a true memory address?
In CPython yes (practically); in general Python terms, consider it a unique identity, not a guaranteed address.

Meet the Walrus Operator (:=) in Python

What is the Walrus Operator?

The Walrus Operator (:=) is an assignment expression. It binds a value to a variable while returning that value, so you can use it immediately within the same expression.

if (n := len(data)) > 5:
    print(f"Too long! ({n} items)")

Why “walrus”? Because := looks like a walrus face with tusks. 🦭

Without vs With Walrus

Without Walrus (two steps):

n = len(data)
if n > 5:
    print(f"Too long! ({n} items)")

With Walrus (one step):

if (n := len(data)) > 5:
    print(f"Too long! ({n} items)")

Benefit: Less repetition, no recomputing len(data).

Real‑World Use Cases

1) Read input until a sentinel

while (line := input(">>> ")) != "quit":
    print("You typed:", line)

Keeps the code compact; no extra variable assignment line is needed before the loop.

2) Avoid duplicate expensive calls

if (user := get_current_user()) and user.is_admin:
    grant_access(user)

You call get_current_user() once, still reuse user.

3) Regex matching, then reuse the match

import re

if (m := re.search(r"order-(\d+)", filename)):
    order_id = int(m.group(1))
    print("Found order:", order_id)

Cleaner than matching first, then writing a second if.

4) Filter/map in one pass

results = [y for x in data if (y := transform(x)) is not None]

Transforms each x and only keeps non‑None results—without calling transform twice.

5) Reading files line by line

with open("log.txt") as f:
    while (chunk := f.read(4096)):
        process(chunk)

Stops when an empty string is returned.

Subtle Gotchas (Readability First!)

1) Parentheses matter

# Good: assign len(data) to n, then compare n > 5
if (n := len(data)) > 5: ...

# Bad: assigns boolean result of (len(data) > 5) to n
if n := len(data) > 5: ...

Prefer the first form to avoid binding a bool to n.

2) Don’t nest too much

Hard‑to‑read one‑liners are worse than two clear lines. If it harms clarity, don’t use walrus.

3) Comprehension scope

In comprehensions, the walrus‑assigned name is local to that comprehension and won’t leak outside—good for avoiding accidental name clashes.

4) Version check

Works in Python 3.8+. If you ship libraries, note this in your README.

Quick Patterns Cheat Sheet

If + reuse

if (val := compute()) is not None:
    use(val)

While + fetch

while (item := queue.get()) is not None:
    handle(item)

Comprehension + cache

pairs = [(name, l) for name in names if (l := len(name)) > 3]

Regex + branch

if (m := re.match(pat, s)): do_something(m)

When Not to Use It

• If it makes the line cryptic (especially for beginners on your team).
• If the expression becomes too long; split into two lines.
• If performance gain is negligible and readability drops.

Mini Exercises (copy → run → learn)

1. Convert this to use a walrus (once), without changing behavior:

data = fetch_data()
if data and len(data) > 10:
    print("Big list:", len(data))

One possible answer:

if (data := fetch_data()) and (n := len(data)) > 10:
    print("Big list:", n)

2. Turn this into a one‑line loop condition:

line = input()
while line != "":
    print(line)
    line = input()

One possible answer:

while (line := input()) != "":
    print(line)

FAQ

Q: Is := the same as =?
A: No. = is a statement (assignment). := is an expression that assigns and returns the value, so you can use it inline.

Q: Does it improve performance?
A: It can, by avoiding repeated function calls. But its biggest win is cleaner code—don’t use it solely for micro‑optimizations.

Q: Is it safe in comprehensions?
A: Yes, it doesn’t leak variables outside the comprehension scope.

Q: Which Python versions support it?
A: Python 3.8+ (PEP 572).

The Hidden Uses of the _ Variable in Python

If you’ve ever written or read Python code, you might have stumbled upon a single underscore ( _ ) used as a variable. At first glance, it looks meaningless — but in reality, _ has several hidden uses that make Python code cleaner and more powerful.

Let’s explore where _ shows up and why it matters.

1. In the Python REPL (Interactive Shell)

When using Python’s REPL (the interactive shell), _ stores the result of the last evaluated expression.

>>> 5 + 7
12
>>> _ * 2
24

Here, _ remembers 12 and multiplies it by 2. It’s a neat shortcut for quick calculations.

2. As a “Throwaway” Variable in Loops

Sometimes you need a loop but don’t actually care about the loop variable. Instead of wasting a variable name, Python convention is to use _.

for _ in range(3):
    print("Hello!")

Output:

Hello!  
Hello!  
Hello!  

This signals to readers: “I’m ignoring the loop variable on purpose.”

3. In Value Unpacking

When unpacking tuples or lists, you can use _ to ignore values you don’t need.

x, _, y = (1, 2, 3)
print(x, y)  # 1 3

This makes code cleaner and easier to read.

4. For Translation in Django (Advanced Use)

In some frameworks like Django, _ is commonly used for marking strings that need translation.

from django.utils.translation import gettext as _

print(_("Hello, World!"))

Here, _ is just an alias for Django’s translation function.

Why It Matters

The underscore (_) isn’t just a random placeholder — it’s a versatile tool in Python that:

• Stores last results in REPL
• Acts as a throwaway variable in loops
• Ignores unwanted values during unpacking
• Supports translation in Django

Key Takeaway

Next time you see _ in Python, don’t ignore it — it’s a tiny variable with big superpowers.