Is requests part of the Python standard library?

No — it's a third-party package (pip install requests), though it has become so ubiquitous that many developers assume it is standard library. The actual standard library HTTP tool is urllib, which requests was specifically designed to be a more ergonomic alternative to.

What is the difference between a connect timeout and a read timeout?

A tuple timeout=(connect_timeout, read_timeout) sets them separately: connect_timeout bounds how long to wait for the initial TCP connection to be established, while read_timeout bounds how long to wait for data once connected. A single timeout=N value applies N to both.

HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

The Python requests Library

Sessions, timeouts, and error handling with requests — the library that made HTTP 'human-friendly' in Python, and the details production code can't skip.

⚡ Total XP: 0|💻 python XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

System Hub

Core logic.

Quick Quiz //

What happens if requests.get(url) is called with no timeout, and the server never responds?

🚀 LEVEL UP TO SENIOR:Unlock 500+ Advanced Practical Challenges & Exercises.

🎓 COURSERA PARTNER:Earn professional Google, Meta, and IBM certificates to supercharge your resume.

requests became Python's dominant HTTP library specifically because it made a genuinely awkward standard-library API (urllib) feel natural. This lesson goes beyond requests.get(url) to the details — sessions, timeouts, and status-code handling — that separate a demo script from production-ready code.

1Timeouts: The Non-Negotiable Default

requests has no default timeout whatsoever — requests.get(url) with no timeout argument will wait, potentially forever, for the server to respond, if the server (or a network device between you and it) simply never sends anything back rather than actively refusing the connection. This is a genuinely common real-world failure mode: a downstream service that's overloaded, deadlocked, or stuck rather than cleanly erroring out, and a client with no timeout has no defense against it — the calling code (and potentially an entire request-handling thread or worker process in a web server) simply hangs indefinitely.

timeout=5 (or a tuple, timeout=(3, 10), specifying separate connect and read timeouts) bounds exactly how long requests will wait before raising requests.exceptions.Timeout, converting an indefinite hang into a bounded, catchable failure your code can actually respond to — retry (using the Retry Strategies techniques from the Advanced Error Handling section), fail gracefully, or surface a clear error to the caller.

The professional default, without exception: every single requests call in production code specifies an explicit timeout. There is essentially no legitimate reason to omit it — even a generous timeout (30 seconds, for a genuinely slow but expected operation) is strictly better than no bound at all, since it converts an unbounded hang into a bounded, recoverable failure.

—

import requests

# DANGEROUS: no timeout -- can hang indefinitely if the server never responds
response = requests.get("https://api.example.com/data")

# CORRECT: always set an explicit timeout
response = requests.get("https://api.example.com/data", timeout=5)

localhost:3000

Bounded Failure

requests.get(url, timeout=5)
Converts an indefinite hang into a catchable Timeout exception

2raise_for_status(): Making HTTP Errors Actually Errors

A crucial, easy-to-miss detail about requests' design: requests.get(url) returning a 404 or 500 response is not, by itself, treated as a Python exception — the call 'succeeds' from Python's perspective exactly as it would for a genuine 200 OK, and response.json() or response.text still work, returning whatever error body the server happened to send back. Code that doesn't explicitly check the status can silently proceed as though a failed request had actually succeeded, processing an error response's JSON body as if it were legitimate data.

response.raise_for_status() closes this gap: it inspects response.status_code, and if it falls in the 4xx (client error) or 5xx (server error) range, raises requests.exceptions.HTTPError — converting an HTTP-level failure into an actual Python exception your code's try/except can catch, following exactly the precise-exception-handling discipline established throughout the Advanced Error Handling section.

The practical pattern this establishes as a near-universal default: response = requests.get(url, timeout=5); response.raise_for_status(); data = response.json() — call raise_for_status() immediately after every request, before doing anything with the response body, so that a failed request fails loudly and immediately at the point of the actual failure, rather than propagating a misleading 'success' further into your code where the eventual failure (a KeyError on an unexpected error-response JSON shape, for instance) would be much harder to trace back to its real cause.

—

response = requests.get(url, timeout=5)
response.raise_for_status()  # raises HTTPError if status is 4xx or 5xx
data = response.json()        # only reached if the request genuinely succeeded

localhost:3000

Explicit Failure Signal

response.raise_for_status()
Turns a 404/500 into a catchable HTTPError, immediately

3Session: Reusing Connections and Shared Configuration

Each standalone requests.get(url) call, by default, establishes a fresh TCP (and, for HTTPS, TLS) connection from scratch — meaningful overhead, especially for HTTPS's additional handshake cost, that's entirely wasted when making multiple requests to the *same* host in succession. requests.Session(), used as a context manager, maintains an underlying connection pool that's reused across every request made through that session object to the same host — a real, measurable performance improvement for any code making more than one request to the same API.

Beyond connection reuse, a Session also lets you set configuration *once* that applies automatically to every subsequent request made through it — session.headers.update({"Authorization": f"Bearer {token}"}) sets an authorization header that every following session.get()/session.post() call automatically includes, eliminating the need to repeat headers={...} on every individual call and the risk of forgetting it on one of them.

The practical rule this establishes: any code making more than one request to the same API or host should use a Session rather than repeated standalone requests.get()/requests.post() calls — it's both a performance improvement (connection reuse) and a correctness improvement (shared configuration applied consistently, impossible to accidentally omit on one specific call).

—

import requests

with requests.Session() as session:
    session.headers.update({"Authorization": f"Bearer {token}"})
    response1 = session.get("https://api.example.com/users")
    response2 = session.get("https://api.example.com/orders")
    # BOTH requests reuse the same underlying TCP connection -- faster, and auth header set once

localhost:3000

Connection & Config Reuse

with requests.Session() as session:
Reused connections, shared headers — set once, applied everywhere

4Step-by-Step Breakdown

requests.get(url) works in a demo. In production, without a timeout, that same line can hang your entire program indefinitely — let's cover what actually needs to be there.

requests.get() without a timeout can hang FOREVER if the server never responds -- always set one explicitly.

Checkpoint: What happens if requests.get(url) is called with no timeout, and the server never responds?

→The call can block indefinitely, potentially freezing the entire program until the connection is somehow interrupted
→requests automatically applies a reasonable default timeout after a few seconds

response.raise_for_status() converts a bad HTTP status (4xx/5xx) into a Python exception -- otherwise a failed request looks identical to a successful one to your code.

Checkpoint: Without calling raise_for_status(), how would code notice that a request returned a 404 Not Found?

→It wouldn't notice automatically — response.json() or response.text would still 'succeed' and return whatever error body the server sent, silently
→requests.get() automatically raises an exception itself whenever the status code is 4xx or 5xx

A Session reuses the underlying TCP connection across multiple requests to the SAME host -- meaningfully faster than a new connection per call.

requests remains the sync HTTP standard; httpx is the modern alternative worth knowing, especially for its async support.

Raise a Real HTTP Error. Finish FakeResponse.raise_for_status(): turn a 4xx/5xx response into a real exception.

Level Up 🚀

Advanced cheat sheets, SEO tricks, and interview prep for this topic.

Browser Support

ChromeSupported

Fully supported (via server-side Python execution).

FirefoxSupported

Fully supported (via server-side Python execution).

SafariSupported

Fully supported (via server-side Python execution).

EdgeSupported

Fully supported (via server-side Python execution).

Best Practices

Always set an explicit timeout on every requests call, with no exceptions

requests has no default timeout — omitting it risks an indefinite hang if a server or network device fails to respond, a genuinely common production failure mode.

Always call raise_for_status() immediately after a request, before processing the response body

A 4xx/5xx response is not automatically an exception in requests — raise_for_status() converts it into one, catching the failure at its actual source instead of letting it propagate misleadingly into your data-processing logic.

Frequent Bugs

THE BUG

Calling requests.get(url) with no timeout in production code, causing the calling thread or process to hang indefinitely if the server or an intermediate network device fails to respond.

THE FIX

Always pass an explicit timeout argument to every requests call, converting a potential indefinite hang into a bounded, catchable Timeout exception.

Real-World Examples

A Resilient API Client Combining Session, Timeout, and Status Checking

A service needs to make multiple authenticated requests to an internal API, correctly bounded by timeouts and properly surfacing any HTTP-level failures.

import requests

class InternalApiClient:
    def __init__(self, base_url: str, token: str):
        self.base_url = base_url
        self.session = requests.Session()
        self.session.headers.update({"Authorization": f"Bearer {token}"})

    def get_user(self, user_id: int) -> dict:
        response = self.session.get(f"{self.base_url}/users/{user_id}", timeout=5)
        response.raise_for_status()
        return response.json()

Interview Prep

?Frequently Asked Questions

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Processing response.json() after a failed request without first calling raise_for_status(), silently treating an error response's body as if it were successful data.

# Wrong: silently processes an error response as if it succeeded
response = requests.get(url, timeout=5)
data = response.json()  # could be an error body, e.g. {"error": "not found"}

# Correct: fails loudly and immediately on an HTTP error
response = requests.get(url, timeout=5)
response.raise_for_status()
data = response.json()

The Solution //

Always call response.raise_for_status() immediately after the request, before accessing .json() or .text, so a failed request raises an exception instead of propagating misleadingly as success.