Twelve questions that
separate junior from senior.

A list and a tuple are both ordered, indexable sequences — but the difference that actually matters in practice is mutability and intent. A tuple is a sealed record; a list is a container you expect to keep changing.

Python passes references to objects, never copies and never "variable slots." Whether a function's edits are visible to the caller depends entirely on whether the object itself is mutable.

The trap, live

Default argument values are evaluated once, at definition time — not on every call. A mutable default becomes a single object shared by every call that omits the argument. Press Call a few times below.

Every generator is an iterator, but not every iterator is a generator. An iterator is any object implementing __iter__ and __next__. A generator is the easy way to get one — write a function with yield, and Python builds the iterator for you.

Step through a generator's lifecycle

This function is paused, not finished, every time it hits yield. Click Next to step through calls to next().

def countdown(n):
    while n > 0:
        yield n
        n -= 1
    print("done")

At pipeline scale, the question isn't "is this faster" — it's "does this fit in memory, and can the next stage start before this one finishes?" A generator yields one record at a time; a list materializes everything before anything downstream can begin.

Concurrency is structure: multiple tasks in progress, interleaved. Parallelism is execution: multiple tasks running at the literal same instant, on multiple cores. A single core can be concurrent but never parallel.

Both let you inject logic outside the view — but they operate at different layers of the request lifecycle, and only one of them runs for non-template responses.

In custom middleware, placed early in the stack — resolving the tenant from the subdomain, a header, or a token claim before any view code runs.

class TenantMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        subdomain = request.get_host().split('.')[0]
        tenant = Tenant.objects.filter(
            schema_name=subdomain, is_active=True
        ).first()
        if tenant is None:
            return HttpResponseNotFound("Unknown tenant")
        request.tenant = tenant
        return self.get_response(request)

No single mechanism is enough — the plan is defense in depth. Each layer below catches what the layer above might miss.

Middleware, authentication classes, permission classes and viewsets could all theoretically know about the tenant — but only one of them should be the resolver. The rest should consume what it produces.

Every DRF action — list, retrieve, update, partial_update, destroy — funnels through get_queryset() (and get_object(), which calls it). Override it once in a base class, and every action inherits the tenant filter.

class TenantScopedQuerySetMixin:
    def get_queryset(self):
        qs = super().get_queryset()
        return qs.filter(tenant=self.request.tenant)


class BaseTenantViewSet(TenantScopedQuerySetMixin, viewsets.ModelViewSet):
    permission_classes = [IsAuthenticated, IsTenantObjectOwner]

    def perform_create(self, serializer):
        # Force the tenant — never trust client input
        serializer.save(tenant=self.request.tenant)

What each action gets, automatically

Queryset scoping is the first wall — but it should never be the only one. Three layers, each catching what the previous one might miss:

class IsTenantObjectOwner(BasePermission):
    def has_object_permission(self, request, view, obj):
        return getattr(obj, 'tenant_id', None) == request.tenant.id

Testing it