Stop Writing Spaghetti if-else Chains: Parsing JSON with Python’s match-case

For those who work in data science, data engineering, or as as a frontend/backend developer, you cope with JSON. For professionals, its principally only death, taxes, and JSON-parsing that’s inevitable. The problem is that parsing JSON is usually a serious pain.

Whether you’re pulling data from a REST API, parsing logs, or reading configuration files, you ultimately find yourself with a nested dictionary that it’s worthwhile to unravel. And let’s be honest: the code we write to handle these dictionaries is usually…ugly to say the least.

We’ve all written the “Spaghetti Parser.” You recognize the one. It starts with a straightforward if statement, but then it’s worthwhile to check if a key exists. Then it’s worthwhile to check if the list inside that key’s empty. Then it’s worthwhile to handle an error state.

Before you already know it, you may have a 40-line tower of if-elif-else statements that’s difficult to read and even harder to take care of. Pipelines will find yourself breaking as a result of some unexpected edge case. Bad vibes throughout!

In Python 3.10 that got here out just a few years ago, a feature was introduced that many data scientists still haven’t adopted: Structural Pattern Matching with match and case. It is usually mistaken for a straightforward “Switch” statement (like in C or Java), but it surely is way more powerful. It means that you can check the and of your data, somewhat than simply its value.

In this text, we’ll take a look at easy methods to replace your fragile dictionary checks with elegant, readable patterns by utilizing match and case. I’ll concentrate on a particular use-case that a lot of us are accustomed to, somewhat than trying to present a comprehension overview of how you may work with match and case.

The Scenario: The “Mystery” API Response

Let’s imagine a typical scenario. You’re polling an external API that you just don’t have full control over. Let’s say, to make the setting concrete, that the API returns the status of an information processing job in a JSON-format. The API is a bit inconsistent (as they often are).

It would return a Success response:

{
    "status": 200,
    "data": {
        "job_id": 101,
        "result": ["file_a.csv", "file_b.csv"]
    }
}

Or an Error response:

{
    "status": 500,
    "error": "Timeout",
    "retry_after": 30
}

Or possibly a weird legacy response that’s just a listing of IDs (since the API documentation lied to you):

[101, 102, 103]

The Old Way: The if-else Pyramid of Doom

For those who were writing this using standard Python control flow, you’d likely find yourself with defensive coding that appears like this:

def process_response(response):
    # Scenario 1: Standard Dictionary Response
    if isinstance(response, dict):
        status = response.get("status")
        
        if status == 200:
            # We've got to watch out that 'data' actually exists
            data = response.get("data", {})
            results = data.get("result", [])
            print(f"Success! Processed {len(results)} files.")
            return results
        
        elif status == 500:
            error_msg = response.get("error", "Unknown Error")
            print(f"Failed with error: {error_msg}")
            return None
        
        else:
            print("Unknown status code received.")
            return None

    # Scenario 2: The Legacy List Response
    elif isinstance(response, list):
        print(f"Received legacy list with {len(response)} jobs.")
        return response
    
    # Scenario 3: Garbage Data
    else:
        print("Invalid response format.")
        return None

Why does the code above hurt my soul?

• It mixes “What” with “How”: You’re mixing business logic (“Success means status 200”) with type checking tools like isinstance() and .get().
• It’s Verbose: We spend half the code just verifying that keys exist to avoid a KeyError.
• Hard to Scan: To know what constitutes a “Success,” you may have to mentally parse multiple nested indentation levels.

A Higher Way: Structural Pattern Matching

Enter the match and case keywords.

As an alternative of asking questions like “Is that this a dictionary? Does it have a key called status? Is that key 200?”, we are able to simply describe the shape of the info we would like to handle. Python attempts to suit the info into that shape.

Here is the very same logic rewritten with match and case:

def process_response_modern(response):
    match response:
        # Case 1: Success (Matches specific keys AND values)
        case {"status": 200, "data": {"result": results}}:
            print(f"Success! Processed {len(results)} files.")
            return results

        # Case 2: Error (Captures the error message and retry time)
        case {"status": 500, "error": msg, "retry_after": time}:
            print(f"Failed: {msg}. Retrying in {time}s...")
            return None

        # Case 3: Legacy List (Matches any list of integers)
        case [first, *rest]:
            print(f"Received legacy list starting with ID: {first}")
            return response

        # Case 4: Catch-all (The 'else' equivalent)
        case _:
            print("Invalid response format.")
            return None

Notice that it’s just a few lines shorter, but that is hardly the one advantage.

Why Structural Pattern Matching Is Awesome

I can provide you with a minimum of three the reason why structural pattern matching with match and case improves the situation above.

1. Implicit Variable Unpacking

Notice what happened in Case 1:

case {"status": 200, "data": {"result": results}}:

We didn’t just check for the keys. We concurrently checked that status is 200 AND extracted the worth of result right into a variable named results.

We replaced data = response.get("data").get("result") with a straightforward variable placement. If the structure doesn’t match (e.g., result is missing), this case is solely skipped. No KeyError, no crashes.

2. Pattern “Wildcards”

In Case 2, we used msg and time as placeholders:

case {"status": 500, "error": msg, "retry_after": time}:

This tells Python: I expect a dictionary with status 500, and value corresponding to the keys "error" and "retry_after". Whatever those values are, bind them to the variables msg and time so I can use them immediately.

3. List Destructuring

In Case 3, we handled the list response:

case [first, *rest]:

This pattern matches list that has a minimum of one element. It binds the primary element to first and the remaining of the list to rest. That is incredibly useful for recursive algorithms or for processing queues.

Adding “Guards” for Extra Control

Sometimes, matching the structure isn’t enough. You wish to match a structure a particular condition is met. You may do that by adding an if clause on to the case.

Imagine we only need to process the legacy list if it comprises fewer than 10 items.

case [first, *rest] if len(rest) < 9:
        print(f"Processing small batch starting with {first}")

If the list is just too long, this case falls through, and the code moves to the subsequent case (or the catch-all _).

Conclusion

I'm not suggesting you replace every easy if statement with a match block. Nevertheless, you need to strongly think about using match and case if you find yourself:

1. Parsing API Responses: As shown above, that is the killer use case.
2. Handling Polymorphic Data: When a function might receive a int, a str, or a dict and wishes to behave in another way for every.
3. Traversing ASTs or JSON Trees: For those who are writing scripts to scrape or clean messy web data.

As data professionals, our job is usually 80% cleansing data and 20% modeling. Anything that makes the cleansing phase less error-prone and more readable is a large win for productivity.

Consider ditching the if-else spaghetti. Let the match and case tools do the heavy lifting as an alternative.

For those who are inquisitive about AI, data science, or data engineering, please follow me or connect on LinkedIn.