TypeError: 'module' object is not callable — Fixed

When you import a Python module but try to call it like a function, you get TypeError: 'module' object is not callable. This one-line mistake is nearly universal—modules are not functions, they don't have a __call__ method, and Python will throw this error the moment you treat them as if they do. This is distinct from the general TypeError: object is not callable error, which covers any non-callable; this post is specifically about the module case. The fix is to either call the function inside the module, or import the function directly. Let's look at the canonical cases and how to spot them fast.

The Core Problem: Modules vs. Functions

Python modules are containers. When you write import datetime, you get a module object—a namespace holding classes, functions, and other objects. But datetime is not itself a function; it's a package with a datetime class inside it. Calling it directly fails:

import datetime

# Wrong: datetime is a module, not callable
result = datetime()  # TypeError: 'module' object is not callable

# Correct: access the datetime class inside the module
result = datetime.datetime(2024, 1, 15)

The error message tells you which object failed: 'module' object is not callable means you're trying to call something that is literally a module. The fix is immediate: either call something inside it, or import what you actually need.

The Three Standard Fixes

Here's the same code with all three working solutions:

Fix 1: Call the class inside the module (dot notation)

import datetime

# Access the datetime class inside the module
now = datetime.datetime.now()
print(now)  # 2024-01-15 14:30:45.123456

Fix 2: Import the class directly

from datetime import datetime

# Now datetime is the class, not the module
now = datetime.now()
print(now)  # 2024-01-15 14:30:45.123456

Fix 3: Alias the module to make the intent clear

import datetime as dt

# Use the alias to distinguish module from class
now = dt.datetime.now()
print(now)  # 2024-01-15 14:30:45.123456

All three are correct. Pick the one that reads clearest in your codebase. The same pattern applies to any stdlib module—socket, random, json, etc.—and to your own modules:

# socket module with the same three fixes
import socket

# Wrong
connection = socket()  # TypeError: 'module' object is not callable

# Right (fix 1)
connection = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# Right (fix 2)
from socket import socket
connection = socket(socket.AF_INET, socket.SOCK_STREAM)

# Right (fix 3)
import socket as sock
connection = sock.socket(sock.AF_INET, sock.SOCK_STREAM)

The Hidden Causes

The obvious cases are easy to spot. The tricky ones hide in refactoring and code structure.

File and Class Share a Name

The classic self-inflicted wound: you create a file mymodule.py that defines a class also called mymodule. When you import it, Python imports the module, not the class:

# mymodule.py
class mymodule:
    def greet(self):
        return "Hello"

# main.py
import mymodule

# Wrong: mymodule is the module, not the class
obj = mymodule()  # TypeError: 'module' object is not callable

# Correct
obj = mymodule.mymodule()
instance = obj.greet()  # "Hello"

The fix is to rename the class or the file. Conventionally, files are snake_case and classes are PascalCase:

# mymodule.py
class MyModule:  # PascalCase class
    def greet(self):
        return "Hello"

# main.py
from mymodule import MyModule
obj = MyModule()  # Works

Partial Module Import, Not Class Import

You meant to import the class but imported the package or submodule instead:

# utils/formats.py
def format_date(d):
    return d.strftime("%Y-%m-%d")

# main.py (wrong)
from utils import formats  # Imports the MODULE, not the function
result = formats("2024-01-15")  # TypeError: 'module' object is not callable

# main.py (correct)
from utils.formats import format_date
result = format_date("2024-01-15")

# OR
from utils import formats
result = formats.format_date("2024-01-15")

Local File Shadowing a Stdlib Module

Your project has a file named random.py, and when you import random, Python finds your file first, not the stdlib module (similar to how cannot-find-module errors work in Node.js, Python's import path is also precedence-based). Your file doesn't have the functions you expect:

# Your file: random.py (in project root)
def shuffle_list(items):
    pass

# Your code: main.py
import random

# Trying to use stdlib
result = random.randint(1, 10)  # Works, reaches your file's module

# But somewhere you try to call random itself
value = random()  # TypeError: 'module' object is not callable
# Because your random.py doesn't define a __call__ method

The culprit is sys.path order. Python searches your project root before the standard library. To check what you actually imported:

import random
print(random.__file__)  # Prints the path to which file Python loaded

If it points to your project's random.py instead of the stdlib, rename yours. Standard practice: don't name your modules after builtins.

Package init.py Not Re-exporting the Class

Your package has an __init__.py that doesn't re-export the class, so accessing package.Thing returns a submodule, not the class:

# mypackage/__init__.py
# (Empty or only imports utilities, not the main class)

# mypackage/core.py
class Thing:
    def __init__(self, value):
        self.value = value

# main.py (wrong)
import mypackage
obj = mypackage.Thing()  # AttributeError or TypeError

# Correct: import the class directly
from mypackage.core import Thing
obj = Thing(42)

# OR: make __init__.py re-export it
# mypackage/__init__.py
from .core import Thing
# Then: import mypackage; obj = mypackage.Thing(42)

Diagnosis: print(type(...)) and print(....file)

When you see this error, debug it in seconds. This is the foundation of error tracking best practices—understanding the root cause before diving into fixes:

import datetime

print(type(datetime))  # <class 'module'> — confirms it's a module
print(datetime.__file__)  # Shows the file path, so you know what you imported
print(type(datetime.datetime))  # <class 'type'> — the datetime class

If type(x) returns <class 'module'>, you're holding a module. Call something inside it. For your own modules, print the file path to confirm you're importing what you think you are.

Python's Callable Protocol

This error exists because Python is explicit about callability. When you write obj(), Python looks for obj.__call__. If it doesn't exist, you get TypeError. Functions, classes, and callable objects have __call__; modules, integers, strings, and lists don't. That design is deliberate—it prevents silent mistakes and makes intent clear.

In Production: Catching It Early

This error almost always surfaces at import time or startup. When your app starts, it imports all its modules. If there's a module/function mismatch, it fails before any user code runs. That's actually good news—it's not a subtle runtime bug that only shows up under load. For a deeper understanding of how to debug production errors, this type of import-time failure is actually one of the easiest to diagnose.

But if it does slip through (maybe only triggered in a specific code path), an error tracker will surface the exact line, the module you tried to call, and the stack leading to that import. With proper error tracking, you see your original code, not obfuscated bytecode.

The fix for TypeError: 'module' object is not callable is always the same: you imported a module, not the function or class inside it. Three lines of working code are shown above—pick the one that fits your codebase's style. The tricky part is spotting the ones hiding in package structure or filename collisions; use print(type(...)) and print(....__file__) to see what you actually loaded.