DEV Community: Michael Interface

How Exposed Postgres view Took 8 Minutes to Retrieve data

Michael Interface — Tue, 24 Feb 2026 14:55:37 +0000

To keep production traffic isolated from heavy reporting queries, we maintain a separate analytics database. Our main service database handles user traffic, while a dedicated analytics database aggregates and enriches organization data.

Twice a day, a background job synchronizes data from analytics into the service database. The analytics team exposes a PostgreSQL view as a clean interface — no direct table access, just a stable SELECT contract.

It worked perfectly.

Until one day the sync started taking 8 minutes.

And the query had a LIMIT 5000.

The Setup

Here’s roughly how the data flowed:

On the analytics side, we had something like this:

analytics.organizations
analytics.organization_domains
analytics.partner_organizations
analytics.custom_projectsThe analytics team exposed a view:

CREATE VIEW analytics.v_sync_organizations AS
    SELECT ... FROM analytics.organizations
    UNION ALL
    SELECT ... FROM analytics.partner_organizations
    UNION ALL
    SELECT ... FROM analytics.custom_projects;

One branch of that view joined organizations with organization_domains and aggregated domains per organization.

The sync job executed something very simple:

SELECT
    org.*,
FROM analytics.v_sync_organizations org
WHERE
    o.website IS NOT NULL
    AND o.address IS NOT NULL
    AND o.display_name IS NOT NULL
ORDER BY o.organization_id
LIMIT 5000;

Nothing scary. Or so we thought.

The Symptom

The job to retrieve the data suddenly started taking over 8 minutes.

From EXPLAIN (ANALYZE, BUFFERS):

Total execution time: 518,803 ms (~8.6 minutes)
Rows returned: 5,000
Rows processed before aggregation: 3,341,534
Temp data written: ~6.6 GB
Temp read time: 407,980 ms (~6.8 minutes)

The database CPU was fine. Memory usage looked normal.

Disk I/O, however, was spiking hard.

The Hidden Problem

One branch of the view looked roughly like this:

SELECT
    org.organization_id,
    MAX(LOWER(d.domain)) AS website,
    org.display_name,
    org.address,
    org.location,
    org.created_at
FROM analytics.organizations org
LEFT JOIN analytics.organization_domains d
    ON org.organization_id = d.organization_id
    AND d.is_primary
GROUP BY
    org.organization_id,
    org.display_name,
    org.address,
    org.location,
    org.created_at;

This is where everything fell apart.

At the time of the incident:

organizations: ~3.1 million rows
organization_domains: ~933,000 rows
Resulting join size: ~3.3 million rows
Row width during sort: ~526 bytes

To perform the GROUP BY, PostgreSQL had to sort those 3.3 million wide rows.

The sort required roughly:

3,341,534 rows × 526 bytes ≈ 1.7 GB

Since that didn’t fit in memory, PostgreSQL switched to an external merge sort.

From the execution plan:

Sort Method: external merge
Disk: 1762616kB

That single sort spilled ~1.7GB to disk. In total, the query wrote ~6.6GB of temporary data and spent over 6 minutes just reading temp files back.

The LIMIT 5000 didn’t help — because PostgreSQL had to complete the aggregation and sorting before it could return the first row.

The Key Realization

We didn’t actually need to group all organization columns.

The real requirement was simple:

For each organization, attach one primary domain.

Instead of grouping everything, we rewrote the query to select a single domain per organization using a lateral subquery:

SELECT
    org.organization_id,
    d.website,
    org.display_name,
    org.address,
    org.location,
    org.created_at
FROM analytics.organizations org
LEFT JOIN LATERAL (
    SELECT LOWER(domain) AS website
    FROM analytics.organization_domains d
    WHERE d.organization_id = org.organization_id
      AND d.is_primary
    ORDER BY domain
    LIMIT 1
) d ON TRUE
WHERE org.location IS NOT NULL;

With an index like:

CREATE INDEX idx_domains_primary_org
ON analytics.organization_domains (organization_id, domain)
WHERE is_primary;

The massive sort disappeared.

No 1.7GB spill. No 6GB temp files. No external merge.

The sync time dropped from 8+ minutes to under 20 seconds.

Closing thoughts

2 main points for me from this incident:

Large GROUP BY operations can silently trigger multi‑gigabyte disk sorts.
Often, the fastest optimization is not tuning memory — but rewriting the query to avoid global aggregation entirely.

And it only surfaced when the data grew large enough to expose it.

I’d love to hear if you had similar problems and how you handled them under real traffic.

When A Landing Page Almost Took Down Production

Michael Interface — Sun, 25 Jan 2026 16:12:34 +0000

Like many B2B startups, our landing page started as a simple marketing surface.

A headline, a short explanation of the product, and a section showing real usage metrics to build trust with potential customers. Nothing fancy. At least, that’s what we thought.

Then traffic happened.

The Business Context

Our product is a B2B workflow automation platform where customers connect third‑party systems (CRMs, payment providers, internal APIs), define trigger‑based rules, and we execute those workflows asynchronously on their behalf — every execution producing rows in our production database.

From a business perspective, one of the strongest trust signals we had was usage. Potential customers wanted to see that the platform was already being used at scale.

That’s why our landing page showed live-ish product metrics:

Number of active companies running workflows
Total workflows executed in the last 30 days
Daily execution volume (displayed as a small chart)
Overall success vs failure rate across all workflows

None of this data was customer-specific. It was fully aggregated and anonymized, but it was real production data.

The Hidden Cost

Behind the scenes, those “simple” numbers were powered by a single API endpoint executing a fairly heavy analytical query against our production database.

To make this concrete, our core tables looked roughly like this:

accounts – one row per customer company
workflows – workflow definitions per account
workflow_runs – one row per execution attempt
workflow_steps – steps inside each workflow
subscriptions – plan and billing state
users – used mainly to exclude internal and test data

The landing page needed to answer questions like:

How many companies ran at least one workflow in the last 30 days?
How many workflow executions happened during that time?
What does daily execution volume look like?
What percentage of runs succeeded vs failed?

The Initial Query

All of this was computed on the fly with a single query that looked roughly like this:

SELECT
    date_trunc('day', wr.created_at) AS day,
    COUNT(DISTINCT a.id) AS active_accounts,
    COUNT(wr.id) AS total_runs,
    COUNT(*) FILTER (WHERE wr.status = 'success') AS successful_runs,
    COUNT(*) FILTER (WHERE wr.status = 'failed') AS failed_runs
FROM workflow_runs wr
JOIN workflows w ON w.id = wr.workflow_id
JOIN accounts a ON a.id = w.account_id
JOIN subscriptions s ON s.account_id = a.id
LEFT JOIN users u ON u.account_id = a.id
WHERE wr.created_at >= now() - interval '30 days'
  AND s.plan != 'free'
  AND u.email NOT LIKE '%@ourcompany.com'
GROUP BY 1
ORDER BY 1;

This query:

Scanned millions of rows in workflow_runs
Joined 6 production tables
Performed multiple aggregations and filters
Returned just a few dozen rows for the UI

On average, it took ~2 seconds. Under load, it could spike to 4–5 seconds.

Early Attempts (and Why They Didn’t Work)

We tried several incremental fixes before changing the architecture.

Indexes and query tuning helped a bit, but the fundamental cost remained: we were still aggregating a large time window of execution data on every request.

Application-level caching reduced the number of queries, but introduced new problems:

When the cache expired, many requests recomputed the same expensive query at once
During cold starts, the landing page always hit production directly
Marketing traffic spikes often arrived exactly when the cache was empty, amplifying the load

Reducing the amount of returned data didn’t help much either. The expensive part wasn’t the result set — it was the computation.

The core issue was simple:

We were running analytical workloads on a transactional database, triggered by anonymous traffic.

Introducing a Materialized View

At that point, we stopped optimizing the query and started questioning the approach.

These metrics didn’t need to be real-time. Being 5 minutes stale had zero business impact. What mattered was predictable performance and protecting production.

We replaced the live query with a materialized view that precomputed all landing page metrics:

CREATE MATERIALIZED VIEW landing_page_metrics AS
SELECT
    date_trunc('day', wr.created_at) AS day,
    COUNT(DISTINCT a.id) AS active_accounts,
    COUNT(wr.id) AS total_runs,
    COUNT(*) FILTER (WHERE wr.status = 'success') AS successful_runs,
    COUNT(*) FILTER (WHERE wr.status = 'failed') AS failed_runs
FROM workflow_runs wr
JOIN workflows w ON w.id = wr.workflow_id
JOIN accounts a ON a.id = w.account_id
JOIN subscriptions s ON s.account_id = a.id
LEFT JOIN users u ON u.account_id = a.id
WHERE wr.created_at >= now() - interval '30 days'
  AND s.plan != 'free'
  AND u.email NOT LIKE '%@ourcompany.com'
GROUP BY 1;

We indexed the materialized view and refreshed it every 5 minutes using REFRESH MATERIALIZED VIEW CONCURRENTLY from a background worker.

From the application’s perspective, the landing page endpoint became a simple, fast read — a single indexed SELECT returning ~30 rows in 10–20 ms, even under peak traffic. No joins, no heavy computation, no surprises.

Closing thought

Materialized views turned a high‑traffic analytical query into a predictable, constant‑time read — regardless of how many users hit the page.

In our case, the fix wasn’t another cache or index. It was changing when the computation happened.

If you’ve solved similar problems — or taken a different approach — I’d love to hear how you handled analytical queries under real traffic.

Keep the User Model Stable (and Let Everything Else Change)

Michael Interface — Sat, 17 Jan 2026 12:38:51 +0000

I treat the User model as one of the few tables in a startup backend that behaves like a public API.

It’s referenced by auth, permissions, analytics, billing — almost everything. Once real users exist, changing User stops being a local refactor and starts being risky.

Over time, I noticed a pattern: we keep attaching fast‑changing business logic to this very stable model.

This post is about a small decision I now make almost by default: keeping the User model stable, and moving volatile requirements into separate models, even when they’re one‑to‑one with User.

The setup: a “simple” quota

A common requirement in startup products is limiting what a user can do.

For example:

how many surveys a user can send
how many invites per month
how many exports per day

The obvious and straight forward implementation looks like this:

-- Naive approach: putting volatile quota fields on the users table
ALTER TABLE users
ADD COLUMN max_surveys_allowed INTEGER DEFAULT 0,
ADD COLUMN surveys_sent_count INTEGER DEFAULT 0;

Two integers. No joins. Easy.

What actually changes in practice

Quota logic changes fast — and not just in small ways.
What starts as a simple per‑user limit usually turns into:

limits per company or per plan
monthly resets instead of lifetime counts
one‑off exceptions for important customers

That’s several structural changes within the first 6–12 months.

The problem is that this volatile logic often lives on the User table — the same table that’s queried on every authenticated request and depended on by auth and permissions.

So a fast‑changing feature ends up forcing risky migrations and updates on one of the most sensitive parts of the system - for example:

locking user rows to update counters on a table that’s read on every request, increasing contention under load
having to audit and coordinate deploys because many unrelated queries assume a specific User table shape

A small but deliberate separation

Instead of extending User, I now model quotas as a separate table with a strict one‑to‑one relationship:

CREATE TABLE user_survey_quotas (
    user_id BIGINT PRIMARY KEY REFERENCES users(id),
    max_surveys_allowed INTEGER NOT NULL,
    surveys_sent_count INTEGER NOT NULL
);

At first glance this looks like additional complexity with extrea table and a new join operation down the line.

In practice, it buys a lot.

Why this holds up better over time

1. Different rates of change

In products I’ve worked on, quota‑related models changed multiple times per year.

The User model, once things stabilized, changed maybe once or twice a year, and often only additively.

Separating them means:

quota changes don’t trigger risky User migrations
rollbacks are easier
experiments are easier to delete

2. Optional complexity

Not every user needs quotas.
With a separate model, it’s trivial to say:

only some users have limits
only paid users get a row
enterprise users override defaults

Trying to encode that with nullable fields on User gets messy fast.

3. Concurrency and correctness

Quota updates are counters.
They usually require:

transactions
row‑level locks
careful increments

Having a dedicated table makes it much clearer what needs to be locked and updated:

-- Safer approach: update quota in its own table with proper locking
BEGIN;

SELECT surveys_sent_count, max_surveys_allowed
FROM user_survey_quotas
WHERE user_id = :user_id
FOR UPDATE;

-- application-side check:
-- if surveys_sent_count >= max_surveys_allowed → reject

UPDATE user_survey_quotas
SET surveys_sent_count = surveys_sent_count + 1
WHERE user_id = :user_id;

COMMIT;

That logic is much harder to reason about when it’s mixed into a large User model with unrelated concerns.

4. Future changes are cheaper

In one product I worked on, quota logic went from:

lifetime limits → monthly resets → plan‑based limits → per‑company overrides

Because it lived outside User, we could rewrite it without touching auth, permissions, or existing queries.
That separation paid for itself very quickly.

Closing thought

My take is simple: I try to keep the User model boring and stable, and push fast‑changing business rules into models that are cheap to evolve or throw away.

Yes, adding a one‑to‑one table is slightly more work up front. But in startup backends, the real cost isn’t joins or extra tables — it’s undoing early decisions once real usage and real business constraints show up.

This approach has paid off for me in multiple projects, but I’m curious how others handle this tradeoff. Do you keep volatile logic off User as well, or have you found cases where it’s not worth the indirection?

How to Use Pytest for Exception Testing: Insights from Open Source Projects

Michael Interface — Mon, 31 Mar 2025 08:42:39 +0000

Testing for exceptions is a crucial part of writing reliable code. Pytest provides powerful tools to check whether a function raises the expected exceptions under specific conditions.

In this post, we'll explore real-world examples of exception testing from popular Python libraries like Celery, Pydantic, Requests, and Jinja. By studying these patterns, you'll learn how to effectively use Pytest to catch and validate exceptions in your own projects.

TLDR

Here are the key exception testing techniques covered in this post using pytest:

Match → Asserting exception messages (Celery)
Inspecting raised exception attributes → Checking detailed validation errors (Pydantic)
Parameterized exception testing → Testing multiple failure cases efficiently (Requests)
Conditional parameterization → Dynamically controlling expected failures (Jinja)
BONUS: Marking expected failures (@pytest.mark.xfail) → Indicating known issues that are expected to fail (Pydantic)

Using `match` to Assert Exception Messages (Celery)

Sometimes, it's not enough to check if an exception is raised—you also want to verify that the exception message matches a specific pattern. Using match inside pytest.raises() lets you validate error messages.

This approach is useful when a function might raise multiple types of exceptions, and you need to ensure that a specific error condition is being met.

Example from Celery:

Celery raises an ImproperlyConfigured error when AWS credentials are missing. Here’s how the test ensures the error message matches expectations:

@patch('botocore.credentials.CredentialResolver.load_credentials')
def test_with_missing_aws_credentials(self, mock_load_credentials):
    self.app.conf.s3_access_key_id = None
    self.app.conf.s3_secret_access_key = None
    self.app.conf.s3_bucket = 'bucket'

    mock_load_credentials.return_value = None

    with pytest.raises(ImproperlyConfigured, match="Missing aws s3 creds"):
        S3Backend(app=self.app)

Another example from Celery:

In this test, Celery raises a ClientError if an operation is attempted on a non-existing S3 bucket. The test uses match with a regular expression to confirm that the error message contains the expected pattern:

def test_with_a_non_existing_bucket(self):
    self._mock_s3_resource()

    self.app.conf.s3_access_key_id = 'somekeyid'
    self.app.conf.s3_secret_access_key = 'somesecret'
    self.app.conf.s3_bucket = 'bucket_not_exists'

    s3_backend = S3Backend(app=self.app)

    with pytest.raises(ClientError, match=r'.*The specified bucket does not exist'):
        s3_backend._set_with_state('uuid', 'another_status', states.SUCCESS)

✅ Takeaway: Use match when you need to ensure the raised exception contains a specific error message. You can also use regular expressions for more flexible matching.

Inspecting Raised Exception Attributes for Validation Details (Pydantic)

Pydantic enforces strict validation rules when parsing input data into models. When an exception is raised, it's often necessary to inspect its attributes to verify the exact validation errors.

Rather than just checking that a ValidationError occurred, you can extract specific error details from the exception. This is especially useful when dealing with multiple potential validation errors.

Example from Pydantic:

In this test, Pydantic is configured to forbid extra fields in the input. The test ensures that passing unexpected fields (bar and spam) triggers the correct validation errors.

def test_forbidden_extra_fails():
    class ForbiddenExtra(BaseModel):
        model_config = ConfigDict(extra='forbid')
        foo: str = 'whatever'

    with pytest.raises(ValidationError) as exc_info:
        ForbiddenExtra(foo='ok', bar='wrong', spam='xx')

    # Extract validation errors from the exception
    assert exc_info.value.errors(include_url=False) == [
        {
            'type': 'extra_forbidden',
            'loc': ('bar',),
            'msg': 'Extra inputs are not permitted',
            'input': 'wrong',
        },
        {
            'type': 'extra_forbidden',
            'loc': ('spam',),
            'msg': 'Extra inputs are not permitted',
            'input': 'xx',
        },
    ]

⚠️ NOTE: Always assert exception attributes outside the pytest.raises() context manager to ensure proper exception handling.

✅ Takeaway: Use the result of the context managerExceptionInfo object to inspect the details of the captured exception.

Using `@pytest.mark.parametrize` to Test Multiple Exception Cases (Requests)

When testing exceptions, you often need to validate different scenarios that trigger similar failures. The Requests library uses @pytest.mark.parametrize() to efficiently test multiple exception cases.

This approach is useful when the same function can fail for multiple reasons, and you want to test all of them in a single test function.

Example from Requests:

Requests uses the next test to raise certain exceptions based on the provided url schema.

@pytest.mark.parametrize(
    "exception, url",
    [
        (MissingSchema, "hiwpefhipowhefopw"),
        (InvalidSchema, "localhost:3128"),
        (InvalidSchema, "localhost.localdomain:3128/"),
        (InvalidSchema, "10.122.1.1:3128/"),
        (InvalidURL, "http://"),
        (InvalidURL, "http://*example.com"),
        (InvalidURL, "http://.example.com"),
    ],
)
def test_invalid_url(self, exception, url):
    with pytest.raises(exception):
        requests.get(url)

✅ Takeaway: Use @pytest.mark.parametrize() to cover multiple exception cases in a single test, reducing duplication.

Conditional Parameterization for Selective Exception Testing (Jinja)

Some test cases need dynamic expectations—certain inputs should raise exceptions, while others should pass. Jinja handles this by conditionally parameterizing tests.

This technique is useful when inputs behave differently based on conditions, and you want your test logic to adapt accordingly.

Example from Jinja:

In this test Jinja makes use of it by checking the template provided as a string with different values.

@pytest.mark.parametrize(
    ("name", "valid"),
    [
        ("foo", True),
        ("föö", True),
        ("き", True),
        ("_", True),
        ("1a", False),  # invalid ascii start
        ("a-", False),  # invalid ascii continue
        ("\U0001f40da", False),  # invalid unicode start
        ("a🐍\U0001f40d", False),  # invalid unicode continue
        # start characters not matched by \w
        ("\u1885", True),
        ("\u1886", True),
        ("\u2118", True),
        ("\u212e", True),
        # continue character not matched by \w
        ("\xb7", False),
        ("a\xb7", True),
    ],
)
def test_name(self, env, name, valid):
    t = "{{ " + name + " }}"
    if valid:
        # valid for version being tested, shouldn't raise
        env.from_string(t)
    else:
        pytest.raises(TemplateSyntaxError, env.from_string, t)

✅ Takeaway: Use conditional assertions when inputs should selectively raise exceptions.

BONUS: Using `@pytest.mark.xfail` to Mark Expected Failures (Pydantic)

Sometimes, you may encounter known bugs or limitations in a library that have yet to be fixed. In such cases, Pytest allows you to mark tests as "expected failures" using @pytest.mark.xfail.

That way you have a test that will pass ones the bug is fixed which simplifies the bug tracking process.
Example from Pydantic:

@pytest.mark.xfail(reason='Waiting for union serialization fixes via https://github.com/pydantic/pydantic/issues/9688.')
def smart_union_serialization() -> None:
    class FloatThenInt(BaseModel):
        value: Union[float, int, str] = Field(union_mode='smart')

    class IntThenFloat(BaseModel):
        value: Union[int, float, str] = Field(union_mode='smart')

    float_then_int = FloatThenInt(value=100)
    assert type(json.loads(float_then_int.model_dump_json())['value']) is int

    int_then_float = IntThenFloat(value=100)
    assert type(json.loads(int_then_float.model_dump_json())['value']) is int

✅ Takeaway: Use @pytest.mark.xfail when testing known issues that are expected to fail but still need to be tracked.

Conclusion

Learning from real-world open-source projects gives us insights into how experienced developers structure their test cases. These projects are battle-tested in production environments, making their testing strategies highly valuable.

📌 All code samples are linked to their original sources, so you can explore the full implementations in context.

Debug Python code interactively

Michael Interface — Sun, 04 Jun 2023 12:44:57 +0000

The debugging process using print statements can get very tedious especially when you don’t really know where the issue might be. Also running the same script multiple times with lots of print statements after each slight change in the code can be time consuming.

The disadvantages with print debugging:

Lots of print statements that only output info about script state for the current run
Lack of knowledge about the state of the whole script
Inability to alter the script for a quick test in the same run

Wouldn't it be nice to make the debugging experience more interactive?

TLDR

Debugging python scripts using python interactive console.

Start you python script in interactive mode: python -i my_script.py

Use python built in code module to drop inside interactive console from you python code:

code.interact(
    banner='Start interactive mode',
    local=locals(),
    exitmsg='Exiting interactive mode')

Interactive mode

You can run your python scripts in interactive mode using the -i parameter in the command line.

# example_sript.py

class Person:
    def __init__(self, age):
        self.age = age

age_list = [19, 4, 55, 14]
person_list = [Person(age=age) for age in age_list]

def display_age_rating():
    for person in person_list:
        if person.age < 18:
            print(f"The content is rated 'M' for mature and can not be shown to a {person.age} year old.")
        else:
            print(f"Being {person.age} year you fall under the mature age group.")

Now run it from inside of your console:

python -i example_sript.py
>>>

From here you get all the advantages of using python interactive console.

Checkout the values of your local variables:

>>> age_list
[19, 4, 55, 14]

Invoke functions:

>>> display_age_rating()
Being 19 year you fall under the mature age group.
The content is rated 'M' for mature and can not be shown to a 4 year old.
Being 55 year you fall under the mature age group.
The content is rated 'M' for mature and can not be shown to a 14 year old.

Change your program state for quick testing:

>>> age_list = [100]*4
>>> age_list
[100, 100, 100, 100]
>>> person_list = [Person(age=age) for age in age_list]
>>> display_age_rating()
Being 100 year you fall under the mature age group.
Being 100 year you fall under the mature age group.
Being 100 year you fall under the mature age group.
Being 100 year you fall under the mature age group.

Use Ctrl+D or type in exit() and press enter to quit the interactive python console.

This method makes debugging experience much more flexible compared to print debugging. But what if you need to debug not a single script but a whole application with multiple files?

Dropping inside interactive mode from inside the code

The built in code python module will allow us to drop inside interactive mode from anywhere in our code during the script execution. To do that we need to invoke interact() function in our script.

# Import code module
import code

class Person:
    def __init__(self, age):
        self.age = age

age_list = [19, 4, 55, 14]
person_list = [Person(age=age) for age in age_list]

def display_age_rating():
    for age in age_list:
        if age < 18:
            print(f"The content is rated 'M' for mature and can not be shown to a {age} year old.")
        else:
            print(f"Being {age} year you fall under the mature age group.")

code.interact(
    banner='Start interactive mode before invoking display_age_rating',
    local=locals(),
    exitmsg='Exiting interactive mode')

display_age_rating()

interact() creates an InteractiveConsole instance. This pauses the execution of the script and starts the read-eval-print loop. It takes in four parameters:

banner accepts a string which will be displayed at the start of the interactive mode instance
local sets a default namespace for the interpreter loop
readfunc can be used as the InteractiveConsole.raw_input() method if provided
exitmsg accepts a string which will be displayed after exiting interactive mode instance

💡 For the local parameter we can manually provide a dictionary of local or global variables that we can access inside interactive mode instance
local={’age_list’: age_list}

Now we can start our small program and use the interactive console the same way as if we provided the -i parameter mentioned previously.

python3 interactive_mode.py                                                                                            
Start interactive mode before invoking display_age_rating
>>> age_list
[19, 4, 55, 14]
>>> display_age_rating()
Being 19 year you fall under the mature age group.
The content is rated 'M' for mature and can not be shown to a 4 year old.
Being 55 year you fall under the mature age group.
The content is rated 'M' for mature and can not be shown to a 14 year old.
>>>

By pressing Ctrl+D we exit current interactive session and let our program finish executing

>>> 
Exiting interactive mode
Being 19 year you fall under the mature age group.
The content is rated 'M' for mature and can not be shown to a 4 year old.
Being 55 year you fall under the mature age group.
The content is rated 'M' for mature and can not be shown to a 14 year old.

We are able to enter interactive console from different parts of our code by placing the interact() function where needed.

import code

age_list = [19, 4, 55, 14]

def display_age_rating():
    for age in age_list:
        code.interact(
            banner='age_list loop iteration',
            local=locals(),
            exitmsg='Exiting interactive mode')

        if age < 18:
            print(f"The content is rated 'M' for mature and can not be shown to a {age} year old.")
        else:
            print(f"Being {age} year you fall under the mature age group.")

code.interact(
    banner='Start interactive mode before invoking display_age_rating',
    local=locals(),
    exitmsg='Exiting interactive mode')
display_age_rating()

That way we are able to jump to the next point of our scripts execution by pressing Ctrl+D.

python3 interactive_mode.py                                                                                       
Start interactive mode before invoking display_age_rating
>>> age_list
[19, 4, 55, 14]
>>> 
Exiting interactive mode
age_list loop iteration
>>> person.age
19
>>> person.age = 100
>>> person.age
100
>>> 
Exiting interactive mode
Being 100 year you fall under the mature age group.
age_list loop iteration
>>> person.age
4
>>> 
Exiting interactive mode
The content is rated 'M' for mature and can not be shown to a 4 year old.
age_list loop iteration
>>>...

To quit the interactive mode use exit().

Conclusion

Python interactive console safes time debugging our code by letting us check the code state and change it on the fly. The code module provides a more flexible way to interact with our code and better understand it’s behavior. For more info check our the official documentation of the code module.

Hopefully this post was helpful. I’d like to now what tools and approaches do you use for debugging your python code. Feel free to comment down below.

DEV Community: Michael Interface

How Exposed Postgres view Took 8 Minutes to Retrieve data

The Setup

The Symptom

The Hidden Problem

The Key Realization

Closing thoughts

When A Landing Page Almost Took Down Production

The Business Context

The Hidden Cost

The Initial Query

Early Attempts (and Why They Didn’t Work)

Introducing a Materialized View

Closing thought

Keep the User Model Stable (and Let Everything Else Change)

The setup: a “simple” quota

What actually changes in practice

A small but deliberate separation

Why this holds up better over time

1. Different rates of change

2. Optional complexity

3. Concurrency and correctness

4. Future changes are cheaper

Closing thought

How to Use Pytest for Exception Testing: Insights from Open Source Projects

TLDR

Using match to Assert Exception Messages (Celery)

Inspecting Raised Exception Attributes for Validation Details (Pydantic)

Using @pytest.mark.parametrize to Test Multiple Exception Cases (Requests)

Conditional Parameterization for Selective Exception Testing (Jinja)

BONUS: Using @pytest.mark.xfail to Mark Expected Failures (Pydantic)

Conclusion

Debug Python code interactively

TLDR

Interactive mode

Dropping inside interactive mode from inside the code

Conclusion

Using `match` to Assert Exception Messages (Celery)

Using `@pytest.mark.parametrize` to Test Multiple Exception Cases (Requests)

BONUS: Using `@pytest.mark.xfail` to Mark Expected Failures (Pydantic)