Skip to content
Python 📅 2026-02-10

How to Resolve Python TypeError: unsupported operand type(s) for +: 'str' and 'int'

🚨 Symptoms & Diagnosis

This TypeError typically surfaces during runtime operand evaluation within arithmetic or string concatenation operations across Python scripts, critical services, or containerized applications. It's a common blocker leading to unhandled exceptions and service interruptions.

TypeError: unsupported operand type(s) for +: 'str' and 'int'

An unhandled exception like this often results in an application exit:

Exit Code: 1 (Python unhandled exception)

Detailed tracebacks will pinpoint the exact line of code causing the type mismatch:

Traceback (most recent call last):
  File "/app/main.py", line 45, in <module>
    result = user_input + 42
TypeError: unsupported operand type(s) for +: 'str' and 'int'

/var/log/python-app/error.log: [2026-02-10 08:00:00] FATAL: Type mismatch in line 45

Root Cause: This error occurs when Python's runtime type system encounters an attempt to perform an operation (like +) between incompatible types, specifically a str and an int or float. Common scenarios include user input, data parsing from logs/APIs, or DataFrame columns being treated as strings when numeric operations are expected.

🛠️ Solutions

Immediate Mitigation: Quick Fix / Inline Type Conversion

Immediate Mitigation: Quick Fix / Inline Type Conversion

This approach provides an immediate runtime fix by explicitly converting the string operand to a numeric type (int or float) just before the operation. Ideal for rapid deployment to mitigate production outages.

  1. Locate the exact failing line using the provided traceback or log messages.
  2. Wrap the string operand with the appropriate type conversion function: int() for integers, float() for floating-point numbers.
  3. Restart the affected Python service or application.
  4. Monitor application logs for recurrence of the TypeError.
# BEFORE (fails)
user_score = input('Score: ')  # User enters '42' (this is a string)
total = user_score + 10  # TypeError: Cannot add 'str' and 'int'

# AFTER (works)
user_score = int(input('Score: '))  # Convert user input to an integer: 42
total = user_score + 10  # Now adds int + int: 52

# Pandas quickfix for DataFrame columns
import pandas as pd
data = {'points': ['10', '20', '30']}
df = pd.DataFrame(data)
print(f"Original dtype: {df['points'].dtype}") # object (string)

# Convert the 'points' column to integer type
df['points'] = df['points'].astype(int)
print(f"New dtype: {df['points'].dtype}") # int64

# Perform arithmetic operation
result = df['points'] + 5
print(result)

Best Practice Fix: Permanent / Type-Safe Refactor

Best Practice Fix: Permanent / Type-Safe Refactor

For robust, production-grade applications, implement defensive programming techniques like try/except blocks for type validation and leverage type hints for clarity and maintainability. This ensures resilience against unexpected input types.

  1. Implement Type Validation: Create a wrapper function or integrate try/except blocks around operations susceptible to type errors.
  2. Robust Error Logging: Ensure any caught ValueError or TypeError is logged with sufficient context (e.g., actual types and values).
  3. Update Dependencies: If using libraries like typeguard for runtime type checking, ensure they are in requirements.txt.
  4. Zero-Downtime Deployment: Deploy the refactored code using your standard CI/CD pipeline, ensuring minimal service disruption.
  5. Unit & Integration Tests: Add unit tests to validate the type-safe functions and integration tests to cover data ingestion points.
import logging
import pandas as pd

# Configure basic logging for demonstration
logging.basicConfig(level=logging.ERROR, format='%(asctime)s - %(levelname)s - %(message)s')
logger = logging.getLogger(__name__)

# type_safe_add.py
def safe_add(a: any, b: any) -> float:
    """
    Safely adds two values, attempting to cast them to float first.
    Logs errors if conversion or addition fails.
    """
    try:
        # Attempt to convert both operands to float for robust numeric addition
        # This handles both int and str representations of numbers
        return float(a) + float(b)
    except (ValueError, TypeError) as e:
        # Log the error with details of the problematic types and values
        logger.error(f'TypeError encountered in safe_add: {e} | operand_a_type={type(a).__name__}, operand_a_value={a}, operand_b_type={type(b).__name__}, operand_b_value={b}')
        # Re-raise the exception to propagate the error, or handle gracefully
        raise ValueError(f"Cannot perform safe_add with types {type(a).__name__} and {type(b).__name__}") from e

# Usage example with safe_add
user_input_str = '42'
user_input_invalid = 'forty-two'

# Valid usage
try:
    result_valid = safe_add(user_input_str, 10)
    print(f"Safe addition (valid): {result_valid}") # Expected: 52.0
except ValueError as e:
    print(f"Error during valid usage: {e}")

# Invalid usage
try:
    result_invalid = safe_add(user_input_invalid, 10)
    print(f"Safe addition (invalid): {result_invalid}")
except ValueError as e:
    print(f"Error during invalid usage: {e}") # Expected: Error logged and re-raised

# Pandas best practice for type consistency and avoiding silent downcasting
# This sets a global option for future DataFrame operations
pd.set_option('future.no_silent_downcasting', True)

# Example with explicit type setting for DataFrame columns
data_pd = {'col_str': ['1', '2', '3'], 'col_int': [4, 5, 6]}
df_safe = pd.DataFrame(data_pd)

# Explicitly cast 'col_str' to int64
df_safe = df_safe.astype({'col_str': 'int64'})
print(f"\nDataFrame dtypes after explicit cast:\n{df_safe.dtypes}")

# Now, operations will be type-safe
result_df = df_safe['col_str'] + df_safe['col_int']
print(f"\nResult of safe DataFrame column addition:\n{result_df}")

🧩 Technical Context (Visualized)

The Python runtime type system rigorously checks operand types during operations. A TypeError like this signifies a fundamental mismatch when an implicit conversion (e.g., string to number) is not performed before a mathematical operation. This often occurs when data sources (user input, APIs, logs) provide values as strings, but the code expects integers or floats for calculations. Explicit type conversion is essential to align the data types with the intended operation.

graph TD
    A["Data Source: user input(), API, Log"] --> B{"Data Retrieval: `str`"};
    B -- `str` value --> C{"Operation: `operand + numeric`"};
    C -- "Incompatible Types (str + int)" --> D[Python Runtime Type System];
    D -- Mismatch --> E(TypeError: 'str' and 'int');
    E --> F{Resolution Strategy};
    F --> G["Explicit Type Conversion: `int()`, `float()`, `.astype()`"];
    G -- Converted to `int` or `float` --> H{"Retried Operation: `numeric + numeric`"};
    H --> I(Successful Numeric Calculation);

✅ Verification

After applying a fix, it's crucial to verify the resolution.

  1. Check Running Processes: 

    ps aux | grep python
    Ensure your Python application is running as expected, ideally without Exit Code: 1 errors.

  2. Tail Application Logs: 

    sudo tail -f /var/log/python-app/error.log | grep TypeError
    Continuously monitor your application's error logs for any further TypeError occurrences.

  3. Test Fix in Python REPL: 

    python3 -c "print(int('42') + 10)"
    This command should execute successfully and print 52, confirming the basic int() conversion logic.

  4. Validate Pandas DataFrame Conversion (in container context): 

    docker exec -it app-container python -c "import pandas as pd; df=pd.DataFrame({'x':['1']}); print(df.astype(int)['x'] + 1)"
    This verifies that DataFrame column type conversions (astype(int)) are working correctly within your containerized environment.

  5. Service Health Check: 

    curl -f http://localhost:8080/health || echo 'FAIL'
    If your service exposes a health endpoint, verify its operational status to ensure the fix hasn't introduced new issues. A 'FAIL' output indicates a problem.

📦 Prerequisites

To effectively diagnose and resolve this issue, you'll generally need:

  • Python 3.9+: For modern features and compatibility.
  • pandas 2.2+: If working with dataframes, for updated astype behaviors and options.
  • Admin/root access: Required for accessing system-level logs (e.g., /var/log/python-app/error.log).
  • docker-compose: Useful for validating fixes within containerized application environments.
  • pip install typeguard (optional): For more rigorous runtime type checking in development or staging environments.