PEP 20: The Zen of Python - Design Philosophy and Guiding Principles

import this

# Beautiful - clean and elegant
users = [user for user in all_users if user.is_active]

# Ugly - verbose and awkward
users = []
for user in all_users:
    if user.is_active == True:
        users.append(user)

# Good - explicit behavior
def send_email(recipient, subject, body, send_immediately=False):
    email = Email(recipient, subject, body)
    if send_immediately:
        email.send()
    else:
        email.queue()

# Bad - implicit behavior
def send_email(recipient, subject, body):
    email = Email(recipient, subject, body)
    email.send()  # Always sends immediately - not obvious

# Simple
total = sum(numbers)

# Complex (unnecessarily)
total = reduce(lambda x, y: x + y, numbers, 0)

# Complex but manageable - single responsibility
class UserManager:
    def __init__(self, db, cache, validator):
        self.db = db
        self.cache = cache 
        self.validator = validator
    
    def create_user(self, user_data):
        self.validator.validate(user_data)
        user = self.db.create(user_data)
        self.cache.invalidate('users')
        return user

# Complicated - tangled responsibilities
class UserManager:
    def create_user(self, user_data):
        # Validation logic mixed with persistence logic
        if not user_data.get('email') or '@' not in user_data['email']:
            raise ValueError("Invalid email")
        # Database logic mixed with caching logic
        with database.transaction() as tx:
            user_id = tx.execute("INSERT INTO users...")
            cache.delete(f"user:{user_id}")
            cache.delete("all_users")
            # More mixed concerns...

# Flat - early returns
def process_user(user):
    if not user:
        return None
    if not user.is_active:
        return None
    if not user.has_permission('read'):
        return None
    
    return user.get_data()

# Nested - pyramid of doom
def process_user(user):
    if user:
        if user.is_active:
            if user.has_permission('read'):
                return user.get_data()
    return None

# Sparse - readable with whitespace
def calculate_score(base_score, multipliers):
    total = base_score
    
    for multiplier in multipliers:
        if multiplier > 0:
            total *= multiplier
    
    return min(total, MAX_SCORE)

# Dense - cramped and hard to read
def calculate_score(base_score, multipliers):
    total=base_score
    for multiplier in multipliers:
        if multiplier>0:total*=multiplier
    return min(total,MAX_SCORE)

# Readable
user_is_authenticated = check_user_credentials(username, password)
if user_is_authenticated:
    grant_access_to_dashboard()

# Less readable
if check_user_credentials(username, password): grant_access_to_dashboard()

# Good - consistent interface
class FileHandler:
    def read(self, filename):
        with open(filename, 'r') as f:
            return f.read()

class DatabaseHandler:
    def read(self, query):
        return self.connection.execute(query).fetchall()

# Bad - breaking consistency for "special" case
class FileHandler:
    def read_file(self, filename):  # Different method name
        with open(filename, 'r') as f:
            return f.read()

class DatabaseHandler:
    def read(self, query):
        return self.connection.execute(query).fetchall()

# Practical - works with real-world constraints
def get_user_data(user_id):
    # Check cache first for performance
    if user_id in cache:
        return cache[user_id]
    
    # Fall back to database
    user_data = database.get_user(user_id)
    cache[user_id] = user_data
    return user_data

# Pure but impractical - always hits database
def get_user_data(user_id):
    return database.get_user(user_id)  # Slow for repeated calls

# Good - handle errors explicitly
def divide_numbers(a, b):
    try:
        return a / b
    except ZeroDivisionError:
        logger.error(f"Division by zero: {a}/{b}")
        raise

# Bad - silent failure
def divide_numbers(a, b):
    try:
        return a / b
    except ZeroDivisionError:
        return None  # Silent failure - caller doesn't know what happened

# Explicitly silenced when appropriate
def optional_feature():
    try:
        import optional_dependency
        return optional_dependency.do_something()
    except ImportError:
        # Explicitly choosing to ignore this error
        logger.debug("Optional dependency not available, skipping feature")
        return None

# Good - explicit about ambiguous parameters
def create_user(name, email=None, username=None):
    if email is None and username is None:
        raise ValueError("Must provide either email or username")
    # Clear logic for each case...

# Bad - guessing what user wants
def create_user(identifier):
    # Guessing whether it's email or username
    if '@' in identifier:
        email = identifier  # Maybe wrong assumption
    else:
        username = identifier

# Python's obvious way to iterate with index
for i, item in enumerate(items):
    print(f"{i}: {item}")

# Less obvious alternatives
for i in range(len(items)):  # More verbose
    print(f"{i}: {items[i]}")

i = 0  # Manual tracking
for item in items:
    print(f"{i}: {item}")
    i += 1

# Python's slice notation - not obvious until you learn it
numbers = list(range(10))
evens = numbers[::2]     # Every second element
odds = numbers[1::2]     # Starting from index 1, every second
reversed_nums = numbers[::-1]  # Reverse

# This reference is to Guido van Rossum being Dutch - some Python 
# features that seem "obvious" to the language designer might not 
# be immediately obvious to everyone else!

# Good - implement basic functionality now
def backup_data():
    """Basic backup - can be improved later"""
    with open('backup.json', 'w') as f:
        json.dump(get_all_data(), f)

# Perfectionist paralysis - never shipping
# def backup_data():
#     """TODO: Implement perfect backup with compression, 
#     encryption, incremental backups, cloud storage, 
#     rollback capability..."""
#     pass  # Never gets implemented

# Good - take time to think through the design
def process_payment(amount, card_info):
    # Wait! This needs careful consideration:
    # - Security implications
    # - Error handling
    # - Logging for audits
    # - Transaction rollback
    # Better to design this properly than rush it
    
    validate_card_info(card_info)
    with transaction():
        charge_result = payment_gateway.charge(amount, card_info)
        log_transaction(charge_result)
        return charge_result

# Bad - rushing critical functionality
def process_payment(amount, card_info):
    return payment_gateway.charge(amount, card_info)  # No validation, logging, etc.

# Hard to explain - bad idea
def mystery_function(data):
    return [x for x in [y[0] if isinstance(y, tuple) and len(y) > 0 
           else y for y in data] if x is not None and str(x).strip()]

# Easy to explain - good idea
def extract_valid_names(data):
    """Extract non-empty names from mixed data types."""
    names = []
    for item in data:
        # Extract first element if it's a tuple, otherwise use item directly
        name = item[0] if isinstance(item, tuple) and len(item) > 0 else item
        
        # Keep only non-empty names
        if name is not None and str(name).strip():
            names.append(name)
    
    return names

# Easy to explain and understand
def calculate_tax(amount, tax_rate):
    """Calculate tax by multiplying amount by tax rate."""
    return amount * tax_rate

def format_currency(amount):
    """Format amount as currency with two decimal places."""
    return f"${amount:.2f}"

# Simple, clear, easy to explain = good ideas

# Good use of namespaces
import datetime
import json.encoder
from pathlib import Path

# Clear what comes from where
today = datetime.date.today()
encoder = json.encoder.JSONEncoder()
config_path = Path("config.json")

# Bad - polluting namespace
from datetime import *
from json import *
from pathlib import *

# Now unclear where things come from
today = date.today()  # Which date?