Python Variables Lab -

Lab 1: The Keyword Test Open your Python shell and try to assign values to keywords.

import keyword
print(keyword.iskeyword("if"))  # True
# Try this:
if = 10 
# Result: SyntaxError

Lab 2: Case Sensitivity Check

score = 10
Score = 20
SCORE = 30
print(score, Score, SCORE)
# Result: 10 20 30 (All stored separately)

Lab 3: The “Hyphen” Trap Try to create a variable with a hyphen and read the error.

my-name = "Guru"
# Result: SyntaxError: cannot assign to operator

Lab 4: The “Throwaway” Variable (Using `_`)

Scenario: You are writing a script to retry a server connection 5 times. You don’t actually need the loop counter number (0, 1, 2…); you just need the loop to run 5 times.

Concept: The underscore _ is a valid variable name, but by convention, it means “I don’t care about this value.”

print("--- Connection Retry Script ---")

# Using 'i' or 'count' implies we will use the number inside.
# Using '_' tells other developers: "Ignore this variable, it's just a placeholder."

for _ in range(3):
    print("Connecting to Database...")

# Result:
# Connecting to Database...
# Connecting to Database...
# Connecting to Database...

# Fun Fact: '_' actually stores the last value!
print(f"The loop finished at index: {_}")

Architect Tip: This is very common in unpacking tuples too!

# We only want the IP, we don't care about the Port or Protocol

server_info = ("192.168.1.1", 8080, "TCP") 
ip, _, _ = server_info 
print(f"Connecting to {ip}")

Lab 5: The “Resource Sanitizer” (Using `.isidentifier()`)

Scenario: You are building a Self-Service Portal where developers can type a name to create a new S3 Bucket or EC2 instance.

The Risk: If they type my-bucket (with a hyphen) or 1st_server, and you try to generate a Python variable or Class name from it dynamically, your automation will crash.
The Fix: Validate input programmatically before processing.

user_inputs = ["prod_db", "1st-database", "backup_v2", "class", "my-app"]

print("--- Validating Resource Names ---")

import keyword

for name in user_inputs:
    # Check 1: Is it a valid identifier?
    # Check 2: Is it a reserved keyword?
    if name.isidentifier() and not keyword.iskeyword(name):
        print(f"✅ '{name}' is a VALID variable name.")
    else:
        print(f"❌ '{name}' is INVALID. Rejecting request.")

# Expected Output:
# ✅ 'prod_db' is a VALID variable name.
# ❌ '1st-database' is INVALID. (Starts with number/has hyphen)
# ✅ 'backup_v2' is a VALID variable name.
# ❌ 'class' is INVALID. (It is a keyword!)
# ❌ 'my-app' is INVALID. (Contains hyphen)

Lab 6: The Unicode “Chaos” Experiment

Scenario: Python 3 supports Unicode variables. Let’s see why this is both cool and dangerous for DevOps.

Task: Create variables using Emoji or Hindi characters.

# Yes, this actually runs in Python 3!
cloud = "AWS"
fire = "High Alert"
सर्वर = "Production Server" # 'Server' written in Hindi

print(f"Deploying to {cloud} status: {fire}")
print(f"Target: {सर्वर}")

# Architect Warning:
# Try running this script on a minimal Linux server (Alpine) inside a Docker container 
# that doesn't have UTF-8 locales installed. It might CRASH or print garbage ().
# ALWAYS use standard English (ASCII) for variable names in scripts!

Lab 7: Global vs. Private Naming Convention

Scenario: You are reading a library code to fix a bug. You see variables named _internal_config and TIMEOUT. What do they mean?

Task: Follow the “Snake Case” and “Constant” conventions.

# 1. Standard Variable (Snake Case) - Use for changing values
current_user = "admin"

# 2. Constant (ALL CAPS) - Use for settings that NEVER change
MAX_RETRIES = 5
API_ENDPOINT = "https://api.devsecopsguru.in"

# 3. Private Variable (Start with _) - "Don't touch this from outside"
_db_password = "secret_pass"

print(f"Connecting to {API_ENDPOINT} with user {current_user}")

# If you see ALL_CAPS in a script, you know immediately: "I should not change this line."