Pre-Docker Advice Meets Containers

Level 1: The Old Map

Imagine someone wrote directions years ago saying, "look for the house with the red mailbox." Later, the whole neighborhood moved into an apartment building, and now every door has a tiny numbered mailbox instead. The old advice was helpful back then, but it does not match the new place. The joke is that the answer was not wrong so much as trapped in the world it came from.

Level 2: Hostnames Are Local

settings.py is commonly associated with Django, a Python web framework. It stores configuration such as allowed hosts, database settings, and environment-specific options. The code in the screenshot imports Python's socket module and calls socket.gethostname() to ask the operating system for the current machine name.

Before containers became common, that might have seemed like a convenient shortcut. If your app ran directly on a server named web-01, the hostname could be a useful clue. With Docker, the app may run inside a container whose name is not the public website name. It might be a generated ID, a temporary label, or a private value that only makes sense inside the deployment system.

For a newer developer, the lesson is simple: configuration should be explicit. If your app needs to know its public URL, give it a setting like PUBLIC_BASE_URL. If it needs to know a database host, pass DATABASE_URL. Do not make the program guess from the computer name unless that is truly what you need. The computer's name and the service's address are related only when the deployment has been designed that way.

Level 3: Advice From Another Era

The screenshot is funny because it captures Stack Overflow aging in public. At the top, an answer says:

I generally put something like this in settings.py:

Then it shows Python reading the hostname and falling back to 'localhost'. Below it, years later, a user points out that Docker breaks the assumption. The author replies:

My solution was written before Docker existed. Sorry.

That is a beautiful little fossil. The answer was written for one deployment world, then discovered by people living in another one. Nobody is necessarily incompetent here. The original author gave practical advice in 2010-era terms. The later user brought 2016-era container expectations. The conflict is not just a bug; it is a timeline mismatch.

This is why old Stack Overflow answers are both essential and dangerous. They encode solved problems, but also the environment in which those problems were solved: bare-metal servers, pets-not-cattle VMs, pre-container deployment assumptions, older Django conventions, looser security defaults, and a casual comfort with bare except: that makes modern reviewers reach for coffee. The answer's green checkmark says "accepted," not "eternally correct under all future infrastructure abstractions."

The real anti-pattern is using runtime introspection as configuration. A web application should usually be told its canonical host through environment variables, settings files, service discovery, or deployment metadata. Guessing it from socket.gethostname() creates a hidden coupling to where the code happens to run. Docker did not create that coupling; Docker merely made it obvious, which is rude but useful.

Level 4: Namespaced Identity Crisis

The tiny socket.gethostname() call in the screenshot sits on top of a real operating-system boundary. In a traditional server process, asking the OS for the hostname often felt like asking, "what machine am I on?" In a containerized process, that question is more slippery because the process may live inside a separate UTS namespace, where hostname identity is isolated from the host machine. Docker can give the container its own hostname, and if none is chosen, that value may look like the container ID rather than a human URL or server name.

That is why the visible complaint lands:

Your solution does not work, if you use Docker. It will show the container ID instead of the URL.

The old answer's code is not doing anything exotic:

import socket

try:
    HOSTNAME = socket.gethostname()
except:
    HOSTNAME = 'localhost'

But the meaning of "hostname" changed under its feet. The call still works. The assumption attached to the call no longer does. That is the classic compatibility trap: APIs can remain stable while infrastructure semantics drift. The same line of Python can be reasonable on a single VM, misleading inside a container, and dangerously wrong if used to construct public URLs, callback endpoints, tenant routing, or environment-specific settings.

The deeper technical lesson is that containers are not small virtual machines in the old administrative sense. They are ordinary processes with selectively isolated views of the system: filesystem mounts, process IDs, networking, users, and host identity can all be scoped differently. When application code treats "what the OS says I am called" as "what clients should call me," it confuses local identity with service identity. DNS names, ingress hosts, load balancer addresses, and configured public base URLs belong in explicit configuration, not in a best-effort hostname guess. Naturally, the guess will work perfectly in staging until the exact minute someone writes a migration guide around it.