What If Python Didn’t Have Variables? I Tried It.

I challenged myself to write Python without using a single variable

What If Python Didn’t Have Variables? I Tried It.
Photo by Shubham Dhage on Unsplash

What happens when you take the most fundamental part of Python… and throw it out?

What If Python Didn’t Have Variables? I Tried It.

Let’s start with a bold claim: Most of us rely on variables way too much in Python.

They’re one of the first things we learn — x = 10, name = "Alice"—but what if we never had them to begin with?

That’s the challenge I gave myself:
Write meaningful Python programs without using a single variable.

No =. No globals(). No locals().
Just pure expressions, functions, and pipelines.

It felt like trying to cook without pots and pans. But surprisingly… it worked. And along the way, I discovered ideas that made me a better programmer — especially when it comes to thinking functionally.


Why Try Variable-Free Python?

Before you laugh me off as a masochist, hear me out.

Here’s what I wanted to explore:

  • Could I write clean, readable code without assigning names to things?
  • How far can functional programming take us in Python?
  • What patterns emerge when you remove the concept of state?

Python is not a purely functional language like Haskell. But it can be expressive, concise, and powerful when treated that way.

Removing variables forces you to rely on:

  • Pure functions
  • Lambda expressions
  • Function chaining (e.g., with functools, itertools, toolz)
  • Closures and recursion
  • Data flowing like a pipeline — not being stored and mutated

In other words, you stop “naming” things and start “flowing” them.

The Rules of the Challenge

To keep things consistent, I set strict rules for this experiment:

  1. No variable assignments — No use of = outside function arguments.
  2. No mutation — No append, +=, or in-place changes.
  3. Only expressions, not statements — Favor lambda, map, filter, reduce, yield, etc.
  4. No global state — Everything must be local, scoped, and passed explicitly.

This meant no for loops, no while, no if x = …, and no named variables like result, temp, or user_data.

Was it easy? Absolutely not.
Was it enlightening? 100%.


A Simple Example: Sum of Squares

Let’s warm up with something easy:

The traditional version:

nums = [1, 2, 3, 4, 5] 
squares = [x**2 for x in nums] 
total = sum(squares) 
print(total)

Variable-free version:

print(sum(map(lambda x: x**2, [1, 2, 3, 4, 5])))

Notice the data flows directly into sum without being named or stored.
It’s not just shorter—it’s conceptually tighter.

Going Deeper: Building a JSON API Parser

Let’s say we’re dealing with an API response:

{ 
  "user": { 
    "id": 123, 
    "profile": { 
      "name": "Alice", 
      "age": 30 
    } 
  } 
}

Traditional approach:

response = get_response() 
user = response["user"] 
profile = user["profile"] 
name = profile["name"]

Variable-free approach:

from operator import itemgetter 
from functools import reduce 
 
print( 
    reduce(itemgetter, ["user", "profile", "name"], get_response()) 
)

Here, reduce(itemgetter, path, data) walks through nested dictionaries without naming any intermediate values.

When It Starts to Hurt (and Teach)

Let’s be honest: Variable-free Python starts getting painful when:

  • You need to debug intermediate steps
  • You repeat the same sub-expression multiple times
  • The code gets deeply nested and unreadable

Example:

# Traditional 
data = fetch_data() 
filtered = [d for d in data if d["active"]] 
names = [d["name"] for d in filtered]

Variable-free:

list( 
    map( 
        itemgetter("name"), 
        filter(lambda d: d["active"], fetch_data()) 
    ) 
)

It works, but it’s harder to read and maintain.
And yet — it forces you to think about data flow instead of storage.

That mindset is incredibly useful when:

  • Writing pipelines (e.g., ETL, data processing)
  • Working with tools like pandas, dbt, Airflow
  • Avoiding bugs from shared mutable state

How Functional Libraries Help

To survive this challenge, I leaned heavily on Python’s functional toolkit:

functools

  • reduce, partial, lru_cache
  • Great for chaining logic without intermediate variables

itertools

  • Lazy iteration, slicing, combining sequences

toolz / funcy / more-itertools

  • Third-party libraries that make functional programming in Python far more expressive
  • Example: pipe, compose, juxt, etc.
from toolz import pipe 
 
pipe( 
    fetch_data(), 
    lambda x: filter(lambda d: d["active"], x), 
    lambda x: map(itemgetter("name"), x), 
    list 
)

This reads top-down like a pipeline — not like procedural soup.

Lessons I Learned

Here’s what stood out after writing Python without variables for a week:

1. Variables Are a Convenience, Not a Necessity

They make debugging and readability easier — but they’re not essential for logic or functionality.

2. Functions Are the Real Building Blocks

By leaning on functions, you start thinking in terms of composition instead of procedures.

3. State Is the Root of Most Bugs

By removing state, you reduce side effects.
It becomes easier to reason about your code’s behavior.

4. Readability Is Contextual

For tiny expressions, no variables can be cleaner.
For complex flows, meaningful names do help.

When You Should (and Shouldn’t) Try This

Try it if you:

  • Want to get better at functional programming
  • Want to build mental models for data flow
  • Want to challenge your assumptions about Python

Avoid it if you:

  • Are writing production code for a team
  • Need to debug frequently or maintain complex logic
  • Don’t have good tests to catch regressions

Final Thoughts

This challenge started as a gimmick — but it became a genuine learning experience.

By taking variables away, I gained:

  • A deeper appreciation for expressions
  • New patterns for chaining logic
  • Better habits for separating concerns

Am I going to stop using variables forever? No.
But now I know when I don’t need them — and that’s a superpower.


Think you rely too much on variables? Try going without them for just one function. You might be surprised what you discover.