Naming Conventions and Restrictions in Python#

🐍 Data Analysis Using Python 🐍 Python Fundamentals Lesson 006

Important

✨ AI-generated content. This page was written with the assistance of an AI language model and is provided as a learning aid. Despite careful review, it may still contain mistakes, omissions, or out-of-date information. Whether you are new to the topic, a team lead, or a senior practitioner, treat it as a starting point rather than an authoritative reference: read it critically and independently verify anything you act on (code, commands, figures, and factual claims) against official documentation and primary sources before relying on it.

Naming well and legally#

Variable names are subject to rules (what Python allows) and conventions (what good practice recommends), and both matter — the rules because breaking them is an error, the conventions because they make code readable. This lesson covers Python’s naming restrictions and conventions, applying the “good names” principle to code.

The restrictions (what Python requires)#

Python enforces rules for valid names:

Allowed characters — names may contain letters, digits, and underscores (_), and must start with a letter or underscore, not a digit. sales_2024 is valid; 2024_sales is not.
No spaces — names cannot contain spaces (use underscores: tax_rate, not tax rate).
Case-sensitive — sales, Sales, and SALES are three different names.
No reserved keywords — Python’s keywords (if, for, class, def, True, and so on) cannot be used as names, since they have special meaning.

Breaking these rules is a syntax error — the code will not run — so the restrictions are non-negotiable.

The conventions (what good practice recommends)#

Beyond legality, Python has widely-followed conventions (codified in the style guide PEP 8) that make code readable:

snake_case for variables and functions — lowercase words joined by underscores: total_sales, tax_rate, customer_count. This is the standard Python style.
Descriptive names — total_sales over ts or x; a name should say what the value is. Clarity over brevity (the foundations’ principle).
UPPER_CASE for constants — values meant not to change (TAX_RATE = 0.08) by convention use all caps.
Avoid confusing names — not single letters like l (looks like 1), not names that shadow built-ins (list, sum, type), which causes subtle bugs.

Conventions are not enforced by Python — code violating them still runs — but following them makes code readable to yourself and others, which is why they are near-universal.

Why naming matters#

Good names are documentation that cannot go out of date. monthly_revenue needs no comment to explain it; mr or x does. As programs grow, the difference between well-named and cryptically-named code is the difference between maintainable and baffling — the exact parallel to well-named versus cryptic data columns. Naming is a small, constant discipline with a large cumulative payoff in readability, which is why it is worth doing deliberately from the start.

The caveat#

The two failure modes are opposite. Under-naming — cryptic abbreviations, single letters, meaningless names — makes code unreadable. But over-naming — names so long they clutter (the_total_amount_of_sales_for_the_northern_region_this_year) — harms readability too, and can tempt breaking the no-spaces rule. The balance is names descriptive enough to be clear, concise enough to read — the same judgement as naming anything. And a name that shadows a built-in (sum = 5 overwriting the sum function) is legal but causes confusing bugs, so convention rightly warns against it. Name for the reader, within the rules. The next lesson covers the types of values names can hold.

Hint