AttributeError: module typing has no attribute Literal in Python

Verified FixPython 3.10+Python 3.10+ / typing_extensionsSilo: core

Quick Fix / Solution Rapide

Import Literal from typing in Python 3.8+ or use from typing_extensions import Literal for backward compatibility with older environments.

Root Cause Analysis

This error occurs when Python tries to import Literal from the standard library typing module (from typing import Literal), but the code is running on a Python version older than Python 3.8 where Literal (PEP 586) was not yet part of the standard library.

1. PEP 586 and the Introduction of Literal in Python 3.8

typing.Literal was introduced in Python 3.8 to allow type annotations that restrict variable values to specific exact literal values (e.g. Literal['r', 'w', 'a']). Running code containing from typing import Literal on Python 3.7 or legacy embedded interpreters raises AttributeError.

2. The Role of the typing_extensions Compatibility Package

The typing_extensions package backports modern typing features (such as Literal, Self, TypeGuard, Annotated) to older Python versions.

3. Name Shadowing of the typing Module

If a project folder contains a local script named typing.py, Python imports the local file instead of the standard library typing module, causing missing attribute errors across all typing imports.

4. Partial Initialization in Embedded Python Environments

Embedded Python runtimes (e.g. in game engines or CAD software) with stripped standard libraries may omit full typing sub-modules.

Reproduction Code (MCVE)

Example: Bug Reproduction

import types

# Simulating legacy environment where typing does not provide Literal
mock_typing = types.ModuleType('typing')
mock_typing.Union = lambda *args: None

# Accessing missing attribute raises AttributeError
literal_type = getattr(mock_typing, 'Literal')

Solution 1: Import from typing in Python 3.8+

Ensure Python 3.8+ is active and import Literal directly from standard library typing.

Example: Recommended Solution

from typing import Literal

# Define literal type constraint
FileMode = Literal['read', 'write', 'append']

def open_file_mode(mode: FileMode) -> str:
    return f'File opened in {mode} mode'

print(open_file_mode('read'))
print(open_file_mode('write'))

Solution 2: Use Safe Fallback with typing_extensions

Use a try/except ImportError block to support both standard library and older environments via typing_extensions.

Example: Alternative Solution

try:
    from typing import Literal
except (ImportError, AttributeError):
    from typing_extensions import Literal

Status = Literal['active', 'inactive']
print(f'Literal type alias initialized: {Status}')

A common mistake is importing Literal from typing_extensions but forgetting to add typing-extensions to requirements.txt. When deployed on a clean server, the import fails with ModuleNotFoundError: No module named 'typing_extensions'. Always declare dependencies explicitly. Edge cases occur with runtime type validation libraries like Pydantic: Pydantic 2.0+ handles typing.Literal natively without extra plugins. Contrast this error with TypeError: Literal[...] cannot be subclassed, which occurs when trying to inherit from a Literal type alias.

Previous Next