# Python Operator Precedence Example
# Understanding how Python evaluates expressions with mixed operators is crucial.

# Scenario 1: Default Precedence
# Multiplication (*) has higher precedence than addition (+).
# Expected: (2 * 3) + 4 = 6 + 4 = 10
result_default = 2 + 3 * 4
print(f"Default Precedence (2 + 3 * 4): {result_default}") # Output: 14 (Incorrect if you expected 2+3 first)

# Scenario 2: Enforcing Order with Parentheses
# Parentheses () override default precedence, forcing the enclosed operation first.
# Expected: (2 + 3) * 4 = 5 * 4 = 20
result_parentheses = (2 + 3) * 4
print(f"Parentheses ( (2 + 3) * 4 ): {result_parentheses}") # Output: 20

# Scenario 3: Exponentiation and Unary Negation
# Exponentiation (**) has higher precedence than unary negation (-).
# Expected: -( (2 ** 3) ) = -(8) = -8
result_exponent_neg = -2 ** 3
print(f"Exponent then Negation (-2 ** 3): {result_exponent_neg}") # Output: -8

# Pitfall: If you intended (-2) ** 3, parentheses are required.
# Expected: (-2) ** 3 = -8
result_neg_exponent = (-2) ** 3
print(f"Negation then Exponent ((-2) ** 3): {result_neg_exponent}") # Output: -8

# Scenario 4: Associativity (Operators of the same precedence)
# Exponentiation (**) is right-associative.
# Expected: 2 ** (3 ** 2) = 2 ** 9 = 512
result_assoc_right = 2 ** 3 ** 2
print(f"Right-Associativity (2 ** 3 ** 2): {result_assoc_right}") # Output: 512

# Most other operators (like +, -, *, /, //, %) are left-associative.
# Expected: (10 - 5) - 2 = 5 - 2 = 3
result_assoc_left = 10 - 5 - 2
print(f"Left-Associativity (10 - 5 - 2): {result_assoc_left}") # Output: 3

# Best Practice: When in doubt, always use parentheses to explicitly define intent.
# This enhances readability and prevents subtle bugs.
result_clear = (2 + 3) * (4 - 1) / (5 ** 2)
print(f"Clear Expression: {result_clear}") # Output: 0.6

# Python Type Coercion and Mismatch Traps
# Understanding how Python handles operations between different data types.

# Scenario 1: Implicit Coercion (Valid)
# Python implicitly converts integers to floats in mixed-type arithmetic.
# Expected: 10.0 + 5.0 = 15.0
result_float = 10 + 5.0
print(f"Implicit int to float (10 + 5.0): {result_float}, Type: {type(result_float)}") # Output: 15.0, Type: <class 'float'>

# Scenario 2: Implicit Coercion (String Concatenation)
# Both operands must be strings for string concatenation using '+'.
# Pitfall: Attempting to concatenate a string with a non-string directly raises a TypeError.
# Uncommenting the line below will cause a TypeError:
# result_str_int = "Value: " + 10
# print(f"String + Int (Error): {result_str_int}")

# Correcting Pitfall 2: Explicit Type Conversion
# Convert the integer to a string before concatenation.
result_str_int_correct = "Value: " + str(10)
print(f"Correct String + Int (\"Value: \" + str(10)): {result_str_int_correct}") # Output: Value: 10

# Scenario 3: Boolean Coercion to Integer
# True acts as 1, False acts as 0 in arithmetic operations.
# Expected: 5 + 1 = 6
result_bool_int = 5 + True
print(f"Boolean to Int (5 + True): {result_bool_int}") # Output: 6

# Expected: 5 + 0 = 5
result_bool_int_false = 5 + False
print(f"Boolean to Int (5 + False): {result_bool_int_false}") # Output: 5

# Scenario 4: Logical Operators with Non-Boolean Types (Truthiness/Falsiness)
# Python evaluates non-boolean values as 'truthy' or 'falsy'.
# Empty sequences, empty strings, 0, None are falsy. All others are generally truthy.
# The 'and' and 'or' operators return one of their operands, not necessarily True/False.

# 'or' returns the first truthy value or the last value if all are falsy.
value_or = 0 or "Hello" or []
print(f"'or' with Truthy (0 or \"Hello\" or []): {value_or}") # Output: Hello

value_or_falsy = [] or {} or None
print(f"'or' with Falsy ([] or {{}} or None): {value_or_falsy}") # Output: None

# 'and' returns the first falsy value or the last value if all are truthy.
value_and = "Hello" and 123 and True
print(f"'and' with Truthy (\"Hello\" and 123 and True): {value_and}") # Output: True

value_and_falsy = "Hello" and 0 and True
print(f"'and' with Falsy (\"Hello\" and 0 and True): {value_and_falsy}") # Output: 0

# Best Practice: Always be conscious of the data types involved in an expression.
# Explicit type conversion using functions like str(), int(), float(), bool() is often safer and clearer.
user_input = "123"
calculated_value = int(user_input) + 45
print(f"Explicit conversion: {calculated_value}") # Output: 168

# Python Boolean Logic and Short-Circuit Evaluation Examples
# Mastering 'and', 'or', and 'not' with truthy/falsy values.

# Scenario 1: Truthiness and Falsiness
# Python evaluates many non-boolean values as True (truthy) or False (falsy).
# Falsy values: False, None, 0, 0.0, '', [], {}, (), set()

# Example of a truthy value
name = "Alice"
if name:
    print(f"'{name}' is a truthy value.") # Output: 'Alice' is a truthy value.

# Example of a falsy value
empty_list = []
if not empty_list:
    print(f"'{empty_list}' is a falsy value.") # Output: '[]' is a falsy value.

# Scenario 2: 'and' Operator with Non-Booleans
# 'and' returns the first falsy operand it encounters.
# If all operands are truthy, it returns the last operand.

result_and_falsy = 0 and "hello"
print(f"0 and \"hello\" returns: {result_and_falsy}") # Output: 0

result_and_truthy = "python" and 10 and [1, 2]
print(f"\"python\" and 10 and [1, 2] returns: {result_and_truthy}") # Output: [1, 2]

# Scenario 3: 'or' Operator with Non-Booleans
# 'or' returns the first truthy operand it encounters.
# If all operands are falsy, it returns the last operand.

result_or_truthy = "" or None or "world"
print(f"\"\" or None or \"world\" returns: {result_or_truthy}") # Output: world

result_or_falsy = {} or 0.0 or False
print(f"{{}} or 0.0 or False returns: {result_or_falsy}") # Output: False

# Scenario 4: Short-Circuit Evaluation Implications
# Operations stop as soon as the result can be determined.
# This can prevent errors or optimize performance.

def might_raise_error():
    # This function would raise a division by zero error if called.
    return 1 / 0

# Using 'and' to guard against execution if 'numerator' is zero.
numerator = 0
denominator = 5
# If numerator is 0, the second part (denominator / numerator) is never evaluated.
safe_division = (numerator != 0) and (denominator / numerator)
print(f"Safe division (0 and ...): {safe_division}") # Output: False (no error)

numerator_ok = 10
safe_division_ok = (numerator_ok != 0) and (denominator / numerator_ok)
print(f"Safe division (True and ...): {safe_division_ok}") # Output: 0.5

# Scenario 5: 'is' vs. '=='
# '==' compares values; 'is' compares identities (memory addresses).

list1 = [1, 2, 3]
list2 = [1, 2, 3]
list3 = list1 # list3 now points to the same object as list1

print(f"list1 == list2: {list1 == list2}") # Output: True (values are equal)
print(f"list1 is list2: {list1 is list2}") # Output: False (different objects in memory)
print(f"list1 == list3: {list1 == list3}") # Output: True
print(f"list1 is list3: {list1 is list3}") # Output: True (same object in memory)

# Pitfall: Using 'is' for value comparison, especially with mutable objects or small integers/strings
# Python caches small integers and some strings, leading to unexpected 'is' results.
# Always use '==' for value comparison unless you specifically need to check identity.
a = 1
b = 1
print(f"1 is 1: {a is b}") # Output: True (due to Python's integer caching)

c = "hello"
d = "hello"
print(f"'hello' is 'hello': {c is d}") # Output: True (due to Python's string interning)

e = [1000]
f = [1000]
print(f"[1000] is [1000]: {e is f}") # Output: False (lists are not interned)

# Use '==' for equality; reserve 'is' for identity or checking for None.
value = None
if value is None:
    print("Value is None, correct use of 'is'.")

# Python Best Practices and Debugging Strategies for Expressions
# Proactive measures and systematic approaches to error detection.

# Best Practice 1: Use Parentheses for Clarity (Even When Not Strictly Needed for Precedence)
# This improves readability and prevents future misunderstandings.

a = 10
b = 5
c = 2

# Less clear, relies on precedence knowledge
result_unclear = a + b * c
# Clearer, explicitly states intent
result_clear = a + (b * c)

print(f"Unclear: {result_unclear}, Clear: {result_clear}")

# Best Practice 2: Break Down Complex Expressions
# Assign intermediate results to descriptive variables.

# Complex expression
def calculate_discounted_price(base_price, discount_percentage, tax_rate):
    # (base_price - (base_price * discount_percentage)) * (1 + tax_rate)
    final_price_complex = (base_price - (base_price * discount_percentage)) * (1 + tax_rate)
    return final_price_complex

# Broken down for clarity and easier debugging
def calculate_discounted_price_clear(base_price, discount_percentage, tax_rate):
    discount_amount = base_price * discount_percentage
    price_after_discount = base_price - discount_amount
    tax_multiplier = 1 + tax_rate
    final_price_clear = price_after_discount * tax_multiplier
    return final_price_clear

price = 100
discount = 0.10 # 10%
tax = 0.05    # 5%

print(f"Complex calculation: {calculate_discounted_price(price, discount, tax)}")
print(f"Clear calculation: {calculate_discounted_price_clear(price, discount, tax)}")

# Best Practice 3: Leverage Assertions for Pre-condition Checks
# Assertions validate assumptions about expression inputs or intermediate states.

def divide(numerator, denominator):
    # Assert that denominator is not zero before proceeding
    assert denominator != 0, "Denominator cannot be zero!"
    return numerator / denominator

try:
    print(f"10 / 2 = {divide(10, 2)}") # Output: 5.0
    # This will raise an AssertionError
    # print(f"10 / 0 = {divide(10, 0)}")
except AssertionError as e:
    print(f"Caught expected error: {e}")

# Debugging Strategy 1: Strategic Print Statements
# Quickly inspect variable values at different stages of an expression.

x = 10
y = 5
z = 2

intermediate_step1 = x + y
print(f"DEBUG: x + y = {intermediate_step1}")

intermediate_step2 = intermediate_step1 * z
print(f"DEBUG: (x+y) * z = {intermediate_step2}")

final_result = intermediate_step2 / 2
print(f"DEBUG: ((x+y)*z) / 2 = {final_result}")

# Debugging Strategy 2: Use a Debugger (pdb - Python Debugger)
# Insert 'breakpoint()' (Python 3.7+) or 'import pdb; pdb.set_trace()'
# This allows step-by-step execution, inspecting variables, etc.

def problematic_function(a, b):
    # breakpoint() # Uncomment to activate pdb
    intermediate = a * b
    final = intermediate + (b / (a - b))
    return final

# problematic_function(5, 5) # This would trigger ZeroDivisionError inside debugger

# Best Practice 4: Utilize Static Analysis Tools (e.g., Flake8, Pylint)
# These tools can catch potential issues before runtime.
# Example: flake8 script.py (run from command line)