Python Variable Naming Rules

Giving a variable a good name is one of the most valuable skills a programmer develops. Python enforces a small set of hard rules: which characters are allowed, which words are forbidden, and where a name can start. Beyond those mechanical constraints sits PEP 8, the community style guide that keeps Python code consistent and readable across teams and years. A well-named variable communicates its purpose instantly, while a poorly named one forces every reader, including your future self, to trace through the code just to understand what a value holds.

This article covers both layers: the hard rules Python enforces and the conventions experienced developers follow. If you have already read about Python variables and how to create and assign them, the naming rules here complete the foundation before reassignment.

What Python allows in a name

A valid identifier must start with a letter or an underscore, and every character after the first can be a letter, a digit, or an underscore. No spaces, hyphens, dots, or other symbols are permitted anywhere in the name:

python

score = 100
player_2 = "Alex"
_first_name = "Sam"
MAX_RETRIES = 3

Names that break this rule raise a syntax error before your program even starts, for example starting a name with a digit, using a hyphen, or leaving a space in the middle. The hyphen restriction surprises people coming from CSS or Lisp, where hyphens are common in names. In Python a hyphen always means subtraction, so the language forces underscores as the standard word separator instead.

A single underscore by itself is a valid name with a few special uses: as a throwaway loop variable when the value does not matter, and in the interactive shell, where it automatically holds the result of the last expression. A leading underscore, such as one variable prefixed with an underscore, is a convention meaning "internal use only." Python does not enforce that convention, but linters and other developers respect it.

Reserved keywords you cannot use

Python reserves 35 words for its own syntax, including false, none, true, class, def, for, if, import, return, and while. Trying to use any of them as a variable name raises a syntax error immediately. Some are obviously off-limits, but short everyday words like type, from, and in also count as keywords and will surprise you the first time you try to use one as a name. If you need a name that conflicts with a keyword, the convention is to append an underscore, so class becomes class_.

Python also has built-in names that are not reserved keywords but are still worth avoiding, including print, len, list, dict, and str. Naming a variable list works without an error, but it shadows the built-in function of the same name for the rest of that scope, and calling it afterward as a function will fail in a confusing way.

PEP 8 conventions for variables and constants

PEP 8 recommends snake_case, all lowercase with underscores between words, for variables, function names, and parameters:

python

user_name = "alex99"
items_count = 42
is_active = True

For values that are not meant to change after being set, the convention shifts to upper case with underscores, as in MAX_CONNECTIONS = 100. Python does not enforce that these stay constant; reassigning an uppercase name later is legal. The uppercase style is only a signal to other developers, though many linters flag reassignment of an uppercase name as a likely mistake.

Class names follow a different style, CapWords, such as UserProfile or HttpClient. Knowing the distinction helps you read unfamiliar code at a glance: a capitalized, no-underscore name is almost always a class, while a lowercase, underscore-separated name is a variable or function.

Choosing names that communicate

Beyond the mechanical rules, the harder skill is choosing a name that answers "what does this value represent" without sending the reader elsewhere in the file. Compare a vague name against a descriptive one:

python

li = ["apple", "banana", "cherry"]
available_fruits = ["apple", "banana", "cherry"]

The first tells you nothing about what the list holds. The second makes the intent obvious at the point of use, which matters most when you are reading a loop or a condition weeks after writing it. Boolean variables benefit from a similar treatment: prefixing them with words like "is" or "has" makes a condition read like a plain sentence instead of a puzzle. Length is a related consideration but not a strict rule of its own. A name should be long enough to be clear and short enough to stay easy to scan; single letters are fine in short loops or math formulas, but everywhere else a descriptive word or two reads better than either extreme.

Case sensitivity and common pitfalls

Python variable names are case-sensitive, so three names that differ only in capitalization are three independent variables. This rarely causes problems when you follow snake_case consistently, since you will not intentionally create two variables that differ only by case. It does mean a stray capital letter in an otherwise familiar name creates a new variable silently, rather than raising an error, so the program keeps running but produces the wrong result. Most editors highlight undefined or newly created names, which is usually your first warning that something was mistyped.

A second pitfall is a name that is valid but misleading, such as a variable called total that actually holds a subtotal. If a name and its value drift apart as a program grows, rename the variable rather than leaving a label that no longer matches what it holds. Consistent, honest naming is what makes a Python codebase easy for someone else, or for you months later, to navigate without re-reading every line.

The next article in this section covers reassigning variables. Naming gets a value its label; reassignment is what lets that label point somewhere new as your program runs.