Python Keywords & Identifiers -- `list` Shadowing Crash

Every language has a vocabulary. English has words like 'the', 'is', and 'if' that carry fixed grammatical meaning — you can't just decide 'if' now means a type of sandwich. Python works the same way. It has a built-in vocabulary of reserved words that power every program ever written in the language, and the moment you open a Python file, those rules are already in force whether you know about them or not. Understanding them isn't optional trivia — it's the foundation everything else is built on.

The problem most beginners hit is that Python's error messages when you misuse keywords are genuinely confusing at first. You try to name a variable 'list' or 'print' and something breaks in a way that doesn't obviously point to a naming problem. Knowing the rules up front means you spend your time actually building things rather than puzzling over cryptic SyntaxError messages at 11 pm.

By the end of this article you'll know every Python keyword by category, you'll be able to write identifiers that are both legal and professional, you'll understand exactly why Python enforces these rules, and you'll be able to spot and fix the three most common beginner naming mistakes on sight. Let's build this up from zero.

What Python Keywords Actually Are — and Why You Can't Touch Them

A Python keyword is a word that is permanently reserved by the language itself. Python's interpreter reads your code word by word, and when it hits a keyword, it doesn't ask what you meant — it already knows. Keywords are the grammar of Python. They're the skeleton that holds every statement together.

Python 3 currently has 35 keywords. Every single one of them serves a specific structural purpose. 'if' starts a condition. 'for' starts a loop. 'def' starts a function. 'True' and 'False' are the only two boolean values. 'None' represents the absence of a value. None of these can be reassigned, overwritten, or used as variable names.

You can see the complete list at any time by running two lines of Python. The 'keyword' module is part of Python's standard library — it ships with Python, no installation needed — and 'keyword.kwlist' gives you the full list in alphabetical order. This is worth memorising not because an interviewer will quiz you on all 35, but because recognising them on sight stops you accidentally walking into a naming collision.

Notice that all 35 keywords are lowercase except 'True', 'False', and 'None'. That capitalisation isn't a style choice — it's part of the specification. Python is case-sensitive, so 'true' (all lowercase) is not a keyword and can technically be used as a variable name, though doing so is a terrible idea for readability.

import keyword  # Python's built-in keyword module — no install needed

# Get the full list of all reserved keywords in your Python version
all_keywords = keyword.kwlist

print(f"Python {__import__('sys').version.split()[0]} has {len(all_keywords)} keywords:\n")

# Print keywords in rows of 5 so they're easy to read
for index, word in enumerate(all_keywords):
    # end='' prevents a newline after each word; we add our own spacing
    print(f"{word:<12}", end='')
    # After every 5th keyword, drop to a new line
    if (index + 1) % 5 == 0:
        print()  # moves the cursor to the next line

print()  # final newline for clean terminal output

# Check whether a specific word is a keyword — returns True or False
word_to_check = "while"
print(f"\nIs '{word_to_check}' a Python keyword? {keyword.iskeyword(word_to_check)}")

word_to_check = "speed"
print(f"Is '{word_to_check}' a Python keyword? {keyword.iskeyword(word_to_check)}")

Python Identifiers — The Naming Rules You Must Know Cold

An identifier is any name you create yourself — variable names, function names, class names, module names. You have freedom here, but Python enforces a firm set of rules. Break any one of them and you get a SyntaxError before your code even runs.

The rules are: (1) An identifier can only contain letters (a–z, A–Z), digits (0–9), and underscores (_). (2) It must not start with a digit — 'player1' is legal, '1player' is not. (3) It must not be a keyword. (4) It cannot contain spaces or special characters like @, $, %, !, or hyphens.

Python is case-sensitive. 'Score', 'score', and 'SCORE' are three completely different identifiers. This catches a lot of beginners who accidentally mix cases when referencing a variable they defined earlier.

Beyond the hard rules, the Python community follows PEP 8 — the official Python style guide. PEP 8 says: use lowercase_with_underscores for variables and functions ('player_score', not 'playerScore'), use CapitalisedWords for class names ('GamePlayer', not 'game_player'), and use ALL_CAPS_WITH_UNDERSCORES for constants ('MAX_SPEED = 300'). These aren't enforced by the interpreter, but every professional Python codebase follows them, and code reviewers will notice immediately if you don't.

Underscores carry special meaning too. A single leading underscore like '_internal_counter' signals to other developers that this is intended for internal use only. A double leading underscore like '__player_id' triggers Python's name mangling inside classes. And '__dunder__' names (double underscore on both sides) are Python's special method names like '__init__' and '__str__'.

# ── LEGAL IDENTIFIERS ─────────────────────────────────────────────────────────

player_name = "Alice"          # lowercase_with_underscores — PEP 8 for variables
player_score = 0               # digits are fine anywhere except the first position
MAX_LEVEL = 100                # ALL_CAPS signals a constant — never meant to change
_checkpoint_data = [1, 5, 9]   # single leading underscore = internal/private use

print(f"Player: {player_name}")
print(f"Score:  {player_score}")
print(f"Max level: {MAX_LEVEL}")
print(f"Checkpoints: {_checkpoint_data}")

# ── CASE SENSITIVITY IN ACTION ────────────────────────────────────────────────

total_coins = 50    # variable 'total_coins' — lowercase
Total_Coins = 200   # COMPLETELY different variable — Python sees a new name entirely

print(f"\ntotal_coins  = {total_coins}")   # prints 50
print(f"Total_Coins  = {Total_Coins}")   # prints 200 — different variable!

# ── PEP 8 CLASS NAMING ────────────────────────────────────────────────────────

class GamePlayer:              # CapitalisedWords (PascalCase) for class names
    def __init__(self, name):  # __init__ is a dunder — Python's constructor method
        self.name = name       # 'self.name' stores the player's name on the object

new_player = GamePlayer("Bob")  # create an instance of GamePlayer
print(f"\nNew player name: {new_player.name}")

# ── WHAT HAPPENS WITH ILLEGAL NAMES — commented out to allow file to run ──────
# 1player = "invalid"    # SyntaxError: starts with a digit
# player-name = "invalid" # SyntaxError: hyphens are not allowed
# for = 10               # SyntaxError: 'for' is a keyword

Keywords by Category — Understanding What Each Group Actually Does

Staring at 35 keywords in alphabetical order is overwhelming. Group them by what they do and the list becomes far more manageable — and far more meaningful.

The value keywords are the simplest: 'True', 'False', and 'None'. These are Python's only built-in literal constants. You'll use all three constantly.

The control-flow keywords — 'if', 'elif', 'else', 'for', 'while', 'break', 'continue', 'pass' — control the direction your code takes. Think of these as the signposts and junctions on a road.

The function and class keywords — 'def', 'return', 'lambda', 'class', 'yield' — are how you define reusable code blocks. 'lambda' creates a tiny one-liner function. 'yield' turns a function into a generator.

The error-handling keywords — 'try', 'except', 'finally', 'raise', 'assert' — are how Python deals with things going wrong. You'll reach for these the moment your programs start handling user input or file operations.

The import keywords — 'import', 'from', 'as' — bring external code into your file. 'as' lets you rename something on import, like 'import numpy as np'.

The scope keywords — 'global', 'nonlocal' — tell Python where a variable lives. The logical operators — 'and', 'or', 'not', 'in', 'is' — build conditions. And 'with', 'del', 'async', 'await' handle context management, deletion, and asynchronous programming respectively.

# This single program intentionally demonstrates keywords from every category.
# Read each section's comment to see which keyword group is in play.

# ── VALUE KEYWORDS: True, False, None ────────────────────────────────────────
game_active = True          # True — one of only two boolean values
high_score_set = False      # False — the other boolean value
last_winner = None          # None — represents 'no value yet'

print("=== Game State ===")
print(f"Game active:      {game_active}")
print(f"High score set:   {high_score_set}")
print(f"Last winner:      {last_winner}")

# ── CONTROL FLOW KEYWORDS: if, elif, else, for, while, break, continue, pass ──
player_lives = 3
current_level = 7

print("\n=== Difficulty Check ===")
if current_level >= 10:           # 'if' starts a condition block
    print("Expert territory!")
elif current_level >= 5:          # 'elif' = else-if — checked only if 'if' was False
    print("Mid-game — stay sharp.")  # this branch runs: level is 7
else:                              # 'else' catches everything else
    print("Just getting started.")

print("\n=== Inventory Scan ===")
inventory = ["sword", "shield", "potion", "torch", "map"]
for item in inventory:            # 'for' loops over each item in the list
    if item == "potion":          # skip the potion — keep it for emergencies
        continue                  # 'continue' jumps straight to the next iteration
    if item == "torch":
        break                     # 'break' exits the loop entirely when torch found
    print(f"  Equipped: {item}")

print("\n=== Lives Countdown ===")
while player_lives > 0:           # 'while' keeps looping as long as condition is True
    print(f"  Lives remaining: {player_lives}")
    player_lives -= 1             # subtract 1 each iteration to avoid infinite loop

# ── FUNCTION KEYWORDS: def, return, lambda ────────────────────────────────────
print("\n=== Scoring Functions ===")

def calculate_bonus(base_score, multiplier):   # 'def' defines a reusable function
    """Returns the final score after applying the bonus multiplier."""
    bonus_score = base_score * multiplier
    return bonus_score                         # 'return' sends the result back to caller

double_points = lambda score: score * 2       # 'lambda' — a one-liner function

final_score = calculate_bonus(150, 3)
print(f"Bonus score:   {final_score}")
print(f"Doubled score: {double_points(final_score)}")

# ── ERROR-HANDLING KEYWORDS: try, except, finally, raise ──────────────────────
print("\n=== Safe Division ===")

def safe_divide(total_points, number_of_players):
    try:                                       # 'try' — attempt this risky operation
        result = total_points / number_of_players
    except ZeroDivisionError:                  # 'except' — caught! handle the error
        print("  Can't divide by zero players — game not started yet.")
        return None
    finally:                                   # 'finally' — runs whether error or not
        print("  Division attempt complete.")
    return result

print(safe_divide(900, 3))   # normal case
print(safe_divide(900, 0))   # triggers ZeroDivisionError

# ── LOGICAL / MEMBERSHIP KEYWORDS: and, or, not, in, is ──────────────────────
print("\n=== Win Condition ===")
has_key = True
boss_defeated = True

if has_key and boss_defeated:   # 'and' — both must be True
    print("You win! Both conditions met.")

print(f"'map' in inventory: {'map' in inventory}")    # 'in' checks membership
print(f"last_winner is None: {last_winner is None}")  # 'is' checks identity

The Silent Danger: Shadowing Built-in Names and Module Names

You now know that keywords like for and if are reserved — you can't use them as variable names. But there's a second, more dangerous category: built-in names like list, str, int, print, len, type, open, and input. These are NOT keywords. keyword.iskeyword('list') returns False. Python lets you assign to them without complaint.

That's the trap. The code runs. No SyntaxError. But somewhere else in your program, something that relied on list(...) or print(...) now breaks with a cryptic error.

Shadowing happens when you use a built-in name as your own identifier in a local scope. If you write list = [1, 2, 3] inside a function, then anywhere inside that function, calling list() will fail with TypeError: 'list' object is not callable. The built-in function is gone, replaced by your list.

The same applies to module names — don't name a file math.py or json.py, because when another module tries import math, Python finds your file first.

The fix is simple: use descriptive, specific names. Instead of list, use item_list or product_ids. Instead of str, use name_str or just name. Add a linting tool that flags shadowed built-in names: flake8-builtins or PyLint's builtin-attribute-shadowing rule.

# ── THE PROBLEM: Shadowing a built-in ───────────────────────────────────────

# This runs fine — no SyntaxError, no warning
def process_orders():
    list = [101, 102, 103]   # 'list' is now a variable, not the constructor!
    print(f"Processing {len(list)} orders")
    
    # Later in the same function...
    new_orders = list([201, 202])  # TypeError: 'list' object is not callable
    # Because 'list' now refers to the list object above, not the built-in function

# ── THE FIX ───────────────────────────────────────────────────────────────────

def process_orders_fixed():
    order_ids = [101, 102, 103]   # descriptive name, no shadowing
    print(f"Processing {len(order_ids)} orders")
    
    new_order_ids = list([201, 202])  # works fine — list() is still the built-in
    
# ── HOW TO CHECK FOR SHADOWED NAMES ───────────────────────────────────────────

import builtins

def check_shadowed_names():
    # Get all built-in names
    builtin_names = dir(builtins)
    # Get names in the current local scope
    local_names = dir()
    
    # Find any that shadow built-ins
    shadowed = [name for name in local_names if name in builtin_names]
    if shadowed:
        print(f"WARNING: You're shadowing these built-in names: {shadowed}")
    else:
        print("No shadowing detected.")

Special Identifiers: Underscore Conventions and Name Mangling

Beyond the hard rules, certain identifier patterns carry special meaning in Python. Understanding them is the difference between writing code that works and writing code that other experienced Python developers can read and maintain.

_single_leading_underscore: This is a convention, not enforced by Python. When you see _helper_function, it means 'this is internal to the module or class — don't use it from outside unless you know what you're doing'. The interpreter doesn't prevent access; it's a signal to other developers.

__double_leading_underscore: This triggers name mangling inside classes. Python renames the attribute to _ClassName__attribute. It exists to avoid naming conflicts in subclasses, not to implement private access. If you define __secret in a class, subclasses won't accidentally override it.

__dunder__ (double underscore both sides): These are Python's special method names, also called 'magic methods' or 'dunder methods'. You've seen __init__ (constructor), __str__ (string representation), __repr__, __len__, __eq__, and many more. Never invent your own dunder names — those are reserved by the language for future use.

Single underscore `_` as a name: Python programmers use _ as a throwaway variable name in loops or unpacking. For example, for _ in range(10): or _, y = point. It tells anyone reading your code 'I don't need this value'.

# ── SINGLE LEADING UNDERSCORE: Internal use convention ──────────────────────
class Player:
    def __init__(self, name):
        self.name = name
        self._hidden_power = 100    # internal — not part of the public API
    
    def attack(self):
        return self._hidden_power * 0.5

p = Player("Alice")
print(p._hidden_power)  # Works fine — but you're violating the convention

# ── DOUBLE LEADING UNDERSCORE: Name mangling ──────────────────────────────────
class Character:
    def __init__(self, name, power):
        self.name = name
        self.__power = power      # name-mangled to _Character__power
    
    def get_power(self):
        return self.__power

class SuperCharacter(Character):
    def __init__(self, name, power, bonus):
        super().__init__(name, power)
        self.__power = power + bonus  # This is a DIFFERENT attribute: _SuperCharacter__power

sc = SuperCharacter("Bob", 10, 5)
print(sc.get_power())           # 10 — parent's __power is unchanged
print(sc._SuperCharacter__power) # 15 — child's __power (accessing mangled name)

# ── DUNDER METHODS ────────────────────────────────────────────────────────────
class Score:
    def __init__(self, value):
        self.value = value
    
    def __str__(self):
        return f"Score: {self.value}"
    
    def __add__(self, other):
        return Score(self.value + other.value)

s1 = Score(10)
s2 = Score(20)
print(s1 + s2)  # calls __add__ -> prints: Score: 30

# ── THROWAWAY UNDERSCORE ──────────────────────────────────────────────────────
coordinates = [(1, 2), (3, 4), (5, 6)]
for _, y in coordinates:        # we don't need x
    print(f"y coordinate: {y}")

Why `is` and `==` Will Burn You in Production — Identifier Identity vs Equality

You think you understand equality checks because you passed a coding quiz. Then you ship a memory-cache layer that breaks because you used is where you meant ==, or vice versa. These aren't interchangeable operators.

== tests value equality. is tests object identity — are both variables pointing to the exact same memory address? Python caches small integers and short strings, so a is b might pass in your test suite and fail in production when those objects fall out of the interning cache.

Always use == for comparing values. Use is only for singleton checks: if value is None, if flag is True. Never use is on strings, integers, or custom objects unless you explicitly control their lifecycle. The moment you compare two database records or config objects with is, you're gambling on CPython's internal optimisations you don't control.

This isn't theoretical. I've debugged cache invalidations that took three days because someone thought is was faster. It's not faster when it's wrong.

// io.thecodeforge — python tutorial

def validate_user_session(cached_obj, fresh_obj):
    # BAD: cached values might be different objects from fresh query
    if cached_obj is fresh_obj:
        return "Session valid"  # Almost never hits
    
    # CORRECT: compare the actual data, not memory addresses
    if cached_obj == fresh_obj:
        return "Session valid"
    return "Session expired"

# Real-world trap with small integers
a = 256
b = 256
print(a is b)  # True — cached by CPython

a = 257
b = 257
print(a is b)  # False — NOT cached, different objects

# What you actually wanted:
print(a == b)  # True — always correct

Name Resolution: Why Python Looks Inside-Out and Your Import Breaks at 3 AM

Python resolves identifier names using the LEGB rule: Local, Enclosing, Global, Built-in. It sounds academic until your module imports a function that shadows a built-in, and your entire script silently starts failing.

When you write print = "hello", you just murdered the built-in print function in that scope. Any code after that line using print() dies with TypeError: 'str' object is not callable. I've seen this in production because someone used list as a variable name, then tried to call list() on a response payload.

Python doesn't warn you. It just walks the LEGB chain, finds your local variable first, and hands you the knife. To protect yourself, always name variables descriptively: user_list instead of list, input_data instead of input. Run import builtins; print(dir(builtins)) and commit that list to memory.

If you must use a shadowed built-in, access it explicitly: import builtins; builtins.print("still works"). But really, just don't shadow.

// io.thecodeforge — python tutorial

import builtins

def crash_reporting():
    # This guy just broke every print() in this scope
    print = "dashboard_v2"  # Oops, shadowed built-in
    
    try:
        # Next line crashes — 'print' is now a string
        print("Generating report...")
    except TypeError as error:
        # Recovery: use the original built-in
        builtins.print(f"Recovered from: {error}")
        builtins.print("Generating report...")

crash_reporting()

# Global scope example — don't do this:
# list = [1, 2, 3]  # Now list() is broken forever
# my_data = list("abc")  # TypeError

Executable Identifiers: Why `eval()` and `exec()` Are a Security Nightmare

You built a config parser that reads user input and runs it through eval() because it was "clean code." Congratulations, you just handed your server keys to anyone who can post __import__('os').system('rm -rf /').

Python identifiers aren't just variable names — when used with eval() or exec(), any valid identifier name becomes an attack vector. A user-controlled string containing globals(), __import__, or os can execute arbitrary code. The worst part? It passes code review because the identifier os looks innocent.

Use ast.literal_eval() for parsing safe Python literals — strings, numbers, tuples, lists, dicts, booleans, and None. That's it. If you need dynamic attribute access, use getattr(obj, "attr_name", default) with a whitelist. Never use eval() on user input. Not once. Not even "just in a test script."

I've cleaned up a production breach where someone used eval() to parse a JSON-like config. The attacker didn't even need to exploit it — a malformed payload crashed the entire service with a generic syntax error that took hours to debug because they'd hidden the eval in a helper function.

// io.thecodeforge — python tutorial

import ast

# NEVER do this — user input goes straight to interpreter
user_input = "__import__('os').system('whoami')"  # Attacker payload
# result = eval(user_input)  # DANGER: this runs the os command

def safe_config_value(raw_input: str):
    """Only parse literal Python objects — no code execution."""
    # Whitelist what's allowed
    allowed_types = {int, float, str, bool, type(None), list, dict, tuple}
    
    try:
        parsed = ast.literal_eval(raw_input)
        if type(parsed) not in allowed_types:
            raise ValueError(f"Type {type(parsed)} not allowed in config")
        return parsed
    except (ValueError, SyntaxError) as e:
        raise ValueError(f"Config parse failed: {e}")

# This works safely
print(safe_config_value("[1, 2, 3]"))  # Safe

# This raises an error instead of executing code
try:
    safe_config_value(user_input)
except ValueError as err:
    print(f"Blocked attack: {err}")

Soft Keywords: match, case, and _ in Python 3.10+

Python 3.10 introduced structural pattern matching with match and case as soft keywords. Unlike hard keywords (e.g., if, for), soft keywords are only reserved in specific contexts. For example, match can be used as a variable name outside a match statement, and case can be used similarly. The underscore _ is also special: in pattern matching, it acts as a wildcard that matches any value but does not bind it. This is a departure from its traditional use as a throwaway variable. Consider:

``python match command: case "quit": exit() case _: print("Unknown command") ``

Here _ matches anything not caught by previous patterns. However, using _ as a variable name elsewhere is still allowed but may confuse readers. Soft keywords reduce backward incompatibility while enabling new syntax. In production, be cautious: using match or case as identifiers in code that may run on Python <3.10 will cause syntax errors. Also, the wildcard _ in pattern matching does not bind a value, so you cannot reference it later. This differs from _ in loops or assignments. Understanding soft keywords helps you write modern Python without breaking legacy compatibility.

# Soft keywords example
match = 42  # Valid: match is a soft keyword
print(match)  # Output: 42

# Pattern matching context
command = "exit"
match command:
    case "quit":
        print("Quitting")
    case _:
        print("Unknown")

# _ as wildcard (does not bind)
point = (0, 0)
match point:
    case (0, 0):
        print("Origin")
    case _:
        print("Not origin")
# _ is not defined after match

Naming Conventions: snake_case, PascalCase, SCREAMING_SNAKE

Python's official style guide, PEP 8, recommends specific naming conventions for different code elements. These conventions are not enforced by the language but are widely adopted for readability and consistency.

• snake_case: Used for variable names, function names, and method names. All lowercase with underscores separating words. Example: user_name, calculate_total().
• PascalCase (also known as UpperCamelCase): Used for class names. Each word starts with an uppercase letter, no underscores. Example: CustomerAccount, DataProcessor.
• SCREAMING_SNAKE: Used for constants. All uppercase with underscores. Example: MAX_RETRIES, DEFAULT_TIMEOUT.

Additionally, single leading underscore _var indicates internal use (by convention), double leading underscore __var triggers name mangling in classes, and double leading and trailing underscore __var__ denotes special methods (dunder methods).

Following these conventions makes your code more predictable and easier for others to understand. For example:

```python # Good class UserProfile: def __init__(self, user_name): self.user_name = user_name

MAX_LOGIN_ATTEMPTS = 3 ```

In production, consistent naming reduces cognitive load and helps static analysis tools. Violating conventions (e.g., using PascalCase for functions) can confuse maintainers. While Python doesn't enforce these rules, adhering to them is a hallmark of professional code.

# Naming conventions example

# snake_case for variables and functions
user_name = "alice"
def get_user_age(user_id):
    return 30

# PascalCase for classes
class UserAccount:
    pass

# SCREAMING_SNAKE for constants
MAX_RETRIES = 5
DEFAULT_TIMEOUT = 30

# Special conventions
_internal_var = "private"  # internal use
__mangled = "name mangling"  # class name mangling
__dunder__ = "special method"  # dunder

Reserved Keywords vs Built-in Names Confusion

A common source of confusion for Python beginners is the difference between reserved keywords and built-in names. Reserved keywords (e.g., if, for, while) are part of the language syntax and cannot be used as identifiers. Attempting to assign to a keyword raises a SyntaxError. Built-in names (e.g., list, dict, print) are functions or types that are always available but are not reserved. You can assign to them, but doing so shadows the original, potentially causing bugs.

For example:

# This is allowed but dangerous
list = [1, 2, 3]
print(list)  # Works, but now list() is overwritten

After this, list no longer refers to the built-in list type. Calling list("abc") later would fail because list is now a list object, not a callable. This is a classic shadowing pitfall.

In contrast, you cannot do:

if = 5  # SyntaxError: invalid syntax

Keywords are syntactically protected; built-in names are not. To avoid confusion, never use built-in names as variable names. Use a linter to warn about shadowing. In production, shadowing a built-in can cause subtle bugs that are hard to trace, especially when the shadowed name is used elsewhere in the codebase.

Remember: keywords are reserved by the language parser; built-in names are just names in the built-in scope that can be overridden. Treat them with the same respect to avoid surprises.

# Reserved keywords cannot be used as identifiers
# if = 5  # SyntaxError

# Built-in names can be shadowed (but shouldn't)
list = [1, 2, 3]  # Shadows built-in list
print(list)  # Output: [1, 2, 3]

# Now list() is broken
# print(list("abc"))  # TypeError: 'list' object is not callable

# Restore original by deleting the shadow
# del list
# print(list("abc"))  # Works again