Python Class Decorators vs Metaclasses Use Cases

Class decorators and metaclasses both modify how Python classes behave, but they operate at different stages of the class lifecycle and solve fundamentally different categories of problems. Choosing the wrong tool leads to fragile code, metaclass conflicts, and unnecessary complexity. This article walks through the specific use cases where each mechanism belongs, with runnable code for every pattern.

Both class decorators and metaclasses fall under the umbrella of metaprogramming, where code writes or modifies other code. The critical distinction is timing. A metaclass participates in the construction of a class object itself, intercepting the process before the class even exists. A class decorator receives a finished class object, modifies or replaces it, and hands it back. That difference in timing determines which tool fits which job.

How Class Creation Works Under the Hood

Before comparing use cases, it helps to understand the exact sequence Python follows when it encounters a class statement. When the interpreter processes a class definition, it collects the class name, base classes, and the class body (executed as a code block). It then looks for a metaclass. If none is specified, it uses type. The metaclass __new__ method builds the actual class object. After the class object is constructed, any class decorator is called with that object as its argument.

Here is a stripped-down example that exposes the order of operations:

copyclass TraceMeta(type):
    def __new__(mcs, name, bases, namespace):
        print(f"metaclass __new__: building {name}")
        cls = super().__new__(mcs, name, bases, namespace)
        print(f"metaclass __new__: {name} built")
        return cls

def trace_decorator(cls):
    print(f"decorator: received {cls.__name__}")
    return cls

@trace_decorator
class Example(metaclass=TraceMeta):
    pass

# Output:
# metaclass __new__: building Example
# metaclass __new__: Example built
# decorator: received Example

The metaclass fires first during construction. The decorator fires second, after construction. This ordering means the decorator always works with a fully formed class. The metaclass can intervene in how that class is formed in the first place.

copy# The decorator is just syntactic sugar:
# Example = trace_decorator(TraceMeta("Example", (), {}))
# The metaclass call must finish before
# the decorator can receive its return value.

copy@trace_decorator               # step 2: receives finished class
class Example(metaclass=TraceMeta):  # step 1: metaclass builds class
    pass

# Output:
# metaclass __new__: building Example   (step 1)
# metaclass __new__: Example built      (step 1)
# decorator: received Example           (step 2)

copy# Python's class creation sequence:
# 1. __prepare__()   -> namespace dict
# 2. execute body    -> fills namespace
# 3. __new__()       -> builds class object
# 4. __init__()      -> initializes class object
# 5. decorator(cls)  -> modifies/replaces class

Class Decorator Use Cases

Class decorators are the right tool when you need to modify a finished class without interfering with how it was constructed. They are simpler to write, easier to compose, and do not introduce metaclass conflicts in inheritance hierarchies.

Wrapping Every Method With Instrumentation

One of the strongest use cases for class decorators is automatically wrapping all methods in a class with logging, timing, or debugging logic. The decorator iterates over the class namespace, identifies callable attributes, and replaces each one with a wrapped version:

copyimport functools
import inspect
import time

def timing_decorator(cls):
    for attr_name, attr_value in list(vars(cls).items()):
        if inspect.isfunction(attr_value) and not attr_name.startswith("_"):
            @functools.wraps(attr_value)
            def timed_method(self, *args, _fn=attr_value, **kwargs):
                start = time.perf_counter()
                result = _fn(self, *args, **kwargs)
                elapsed = time.perf_counter() - start
                print(f"{cls.__name__}.{_fn.__name__} took {elapsed:.6f}s")
                return result
            setattr(cls, attr_name, timed_method)
    return cls

@timing_decorator
class DataProcessor:
    def transform(self, data):
        return [x * 2 for x in data]

    def aggregate(self, data):
        return sum(data)

processor = DataProcessor()
processor.transform(range(100_000))
processor.aggregate(range(100_000))

This pattern works because the decorator only needs to inspect and replace attributes on an already-constructed class. There is no reason to involve a metaclass here, and doing so would prevent you from stacking additional decorators without conflicts. The functools.wraps decorator used inside the wrapper ensures the original method's name and docstring are preserved on the replacement.

Singleton Pattern via Class Decorator

The singleton pattern restricts a class to a single instance. A class decorator handles this cleanly by overriding the class __new__ method:

copydef singleton(cls):
    original_new = cls.__new__
    original_init = cls.__init__
    instance = None

    def __new__(klass, *args, **kwargs):
        nonlocal instance
        if instance is None:
            instance = original_new(klass)
        return instance

    def __init__(self, *args, **kwargs):
        if getattr(self, "_singleton_initialized", False):
            return
        original_init(self, *args, **kwargs)
        self._singleton_initialized = True

    cls.__new__ = __new__
    cls.__init__ = __init__
    return cls

@singleton
class AppConfig:
    def __init__(self):
        self.debug = False
        self.db_url = "sqlite:///app.db"

config_a = AppConfig()
config_b = AppConfig()
print(config_a is config_b)  # True

The decorator approach preserves the class identity. isinstance(config_a, AppConfig) returns True, and the class retains its original name and docstring. The __init__ guard prevents re-initialization of the cached instance on subsequent calls. This is an advantage over function-wrapper-based decorators that replace the class with a closure, which breaks isinstance checks.

Injecting Class Attributes and Methods

Class decorators work well for adding attributes, classmethods, or entire protocol implementations after the class body has been defined:

copydef add_repr(cls):
    def __repr__(self):
        attrs = ", ".join(
            f"{k}={v!r}" for k, v in vars(self).items()
            if not k.startswith("_")
        )
        return f"{cls.__name__}({attrs})"
    cls.__repr__ = __repr__
    return cls

def add_eq(cls):
    def __eq__(self, other):
        if not isinstance(other, cls):
            return NotImplemented
        return vars(self) == vars(other)
    cls.__eq__ = __eq__
    return cls

@add_repr
@add_eq
class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

p1 = Point(3, 4)
p2 = Point(3, 4)
print(p1)        # Point(x=3, y=4)
print(p1 == p2)  # True

Notice how two decorators stack cleanly. Trying this with two separate metaclasses would immediately produce a TypeError about metaclass conflicts. This composability is exactly why class decorators are recommended over metaclasses for composable class extensions. For a detailed walkthrough of how Python evaluates chained decorator execution order, see the dedicated article on that topic.

copyimport inspect

class Example:
    @staticmethod
    def static_one(): pass
    def regular(self): pass

for name, val in vars(Example).items():
    if not name.startswith("_"):
        print(f"{name}: callable={callable(val)}, "
              f"isfunction={inspect.isfunction(val)}")
# static_one: callable=True,  isfunction=False
# regular:    callable=True,  isfunction=True

copy# Safe pattern for class decorators:
import inspect

def my_decorator(cls):
    for name, val in list(vars(cls).items()):
        if inspect.isfunction(val) and not name.startswith("_"):
            # Only matches regular instance methods
            setattr(cls, name, wrap(val))
    return cls

copy# callable() is safe to call on anything:
print(callable(42))            # False
print(callable("hello"))       # False
print(callable(lambda: None))  # True
print(callable(staticmethod(lambda: None)))  # True

Metaclass Use Cases

Metaclasses operate at a lower level, controlling how the class object itself is assembled. They become necessary when the decorator approach is insufficient, specifically when you need to intervene before or during class creation rather than after it.

Automatic Subclass Registration

Frameworks like ORMs and plugin systems need to know about every class that inherits from a base. A metaclass handles this naturally because it fires on every subclass, including nested ones deep in the hierarchy:

copyclass PluginMeta(type):
    _registry = {}

    def __new__(mcs, name, bases, namespace):
        cls = super().__new__(mcs, name, bases, namespace)
        if bases:  # skip the base class itself
            plugin_name = namespace.get("name", name.lower())
            mcs._registry[plugin_name] = cls
        return cls

    @classmethod
    def get_plugin(mcs, name):
        return mcs._registry.get(name)

class Plugin(metaclass=PluginMeta):
    """Base class for all plugins."""
    name = None

class JSONExporter(Plugin):
    name = "json"

    def export(self, data):
        import json
        return json.dumps(data)

class CSVExporter(Plugin):
    name = "csv"

    def export(self, data):
        return "\n".join(",".join(str(v) for v in row) for row in data)

# Registration happened automatically at class definition time
exporter_cls = PluginMeta.get_plugin("json")
exporter = exporter_cls()
print(exporter.export({"key": "value"}))  # {"key": "value"}

The key difference from a decorator approach here is that subclasses of JSONExporter or CSVExporter would also be automatically registered. A decorator only applies to the single class it decorates. The metaclass propagates down the entire inheritance tree without any additional annotation on each subclass.

Validating Class Structure at Definition Time

Metaclasses can enforce that classes conform to a specific interface or naming convention before any instance is ever created:

copyclass InterfaceMeta(type):
    _required_methods = set()

    def __new__(mcs, name, bases, namespace):
        cls = super().__new__(mcs, name, bases, namespace)

        # Skip validation on the abstract base
        if bases and any(isinstance(b, InterfaceMeta) for b in bases):
            missing = []
            for method_name in mcs._required_methods:
                if method_name not in namespace:
                    missing.append(method_name)
            if missing:
                raise TypeError(
                    f"{name} must implement: {', '.join(missing)}"
                )
        return cls

class SerializerMeta(InterfaceMeta):
    _required_methods = {"serialize", "deserialize"}

class Serializer(metaclass=SerializerMeta):
    """All serializers must implement serialize() and deserialize()."""
    pass

class ValidSerializer(Serializer):
    def serialize(self, obj):
        return str(obj)

    def deserialize(self, data):
        return eval(data)

# This would raise TypeError at class definition time:
# class BrokenSerializer(Serializer):
#     def serialize(self, obj):
#         return str(obj)
#     # Missing deserialize -- TypeError raised immediately

The validation happens at import time, not at instantiation time. This is a significant advantage for large codebases where a malformed class might not be instantiated until runtime in production. The metaclass catches the problem the moment Python loads the module.

Controlling Instance Creation With __call__

A metaclass can override __call__ to intercept what happens when you call MyClass() to create an instance. This is more powerful than overriding __new__ on the class itself, because the metaclass __call__ wraps both __new__ and __init__:

copyfrom threading import Lock

class ThreadSafeSingletonMeta(type):
    _instances = {}
    _lock = Lock()

    def __call__(cls, *args, **kwargs):
        with cls._lock:
            if cls not in cls._instances:
                instance = super().__call__(*args, **kwargs)
                cls._instances[cls] = instance
            return cls._instances[cls]

class DatabaseConnection(metaclass=ThreadSafeSingletonMeta):
    def __init__(self, connection_string="default"):
        self.connection_string = connection_string
        self.connected = True

    def query(self, sql):
        return f"Executing: {sql}"

db1 = DatabaseConnection("postgres://localhost/mydb")
db2 = DatabaseConnection("postgres://localhost/other")
print(db1 is db2)                # True
print(db1.connection_string)     # postgres://localhost/mydb

The metaclass __call__ approach for singletons is thread-safe and preserves full class identity, including isinstance checks and proper method resolution order. It also propagates to subclasses automatically, so any class inheriting from DatabaseConnection gets its own singleton behavior without additional decorators.

Customizing the Namespace With __prepare__

Metaclasses have exclusive access to __prepare__, which controls the dictionary used to collect the class body during execution. This has no equivalent in class decorators:

copyclass NoDuplicatesMeta(type):
    @classmethod
    def __prepare__(mcs, name, bases):
        return _NoDupDict()

    def __new__(mcs, name, bases, namespace):
        # Convert back to regular dict for the actual class
        return super().__new__(mcs, name, bases, dict(namespace))

class _NoDupDict(dict):
    def __setitem__(self, key, value):
        if key in self and key != "__module__" and key != "__qualname__":
            raise TypeError(
                f"Duplicate definition of '{key}' in class body"
            )
        super().__setitem__(key, value)

class Config(metaclass=NoDuplicatesMeta):
    timeout = 30
    retries = 3
    # timeout = 60  # Would raise TypeError: Duplicate definition

The __prepare__ hook is called before the class body executes, returning the mapping that the interpreter uses as the local namespace for the class body. This is the one capability that is completely impossible to replicate with a class decorator, because by the time a decorator runs, the class body has already executed and any duplicate definitions have silently overwritten earlier ones.

It is worth noting that one of the historically prominent __prepare__ use cases has been eliminated by language evolution. Before Python 3.7, the only way to preserve the definition order of class body attributes was to have __prepare__ return an OrderedDict. This mattered for ORMs and serialization libraries that needed fields processed in the order the developer wrote them. Since Python 3.7 guarantees that all dict objects maintain insertion order, this entire category of __prepare__ usage is obsolete. The remaining legitimate __prepare__ use cases are narrower: custom namespace objects that intercept assignments (like the duplicate detection example above), logging or tracing attribute definitions as they happen, or supplying a namespace that provides default values for names referenced in the class body.

copyclass Plugin:
    _registry = {}

    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        Plugin._registry[cls.__name__] = cls

class JSONPlugin(Plugin): pass
class CSVPlugin(Plugin): pass

print(Plugin._registry)
# {'JSONPlugin': ..., 'CSVPlugin': ...}

copy# Only a metaclass can intercept this:
class LoggingMeta(type):
    @classmethod
    def __prepare__(mcs, name, bases):
        class LoggingDict(dict):
            def __setitem__(self, key, val):
                print(f"  defining: {key}")
                super().__setitem__(key, val)
        return LoggingDict()

    def __new__(mcs, name, bases, ns):
        return super().__new__(mcs, name, bases, dict(ns))

class Config(metaclass=LoggingMeta):
    timeout = 30   # prints: defining: timeout
    retries = 3    # prints: defining: retries

copyimport functools, inspect

def log_all_methods(cls):
    for name, val in list(vars(cls).items()):
        if inspect.isfunction(val):
            @functools.wraps(val)
            def wrapper(*a, _fn=val, **kw):
                print(f"calling {_fn.__name__}")
                return _fn(*a, **kw)
            setattr(cls, name, wrapper)
    return cls

The __init_subclass__ Middle Ground

Python 3.6 introduced __init_subclass__ through PEP 487, specifically to cover the majority of real-world metaclass use cases without requiring a metaclass at all. The hook is defined as a regular method on a parent class and is automatically called whenever that parent is subclassed.

copyclass EventHandler:
    _handlers = {}

    def __init_subclass__(cls, event_type=None, **kwargs):
        super().__init_subclass__(**kwargs)
        if event_type is not None:
            cls._handlers[event_type] = cls

    @classmethod
    def dispatch(cls, event_type, payload):
        handler_cls = cls._handlers.get(event_type)
        if handler_cls is None:
            raise ValueError(f"No handler for event: {event_type}")
        return handler_cls().handle(payload)

class ClickHandler(EventHandler, event_type="click"):
    def handle(self, payload):
        return f"Handled click on {payload['element']}"

class SubmitHandler(EventHandler, event_type="submit"):
    def handle(self, payload):
        return f"Handled submit of {payload['form']}"

result = EventHandler.dispatch("click", {"element": "button"})
print(result)  # Handled click on button

This achieves the same automatic registration that required a metaclass in earlier Python versions. The syntax is cleaner: keyword arguments in the class definition line (event_type="click") pass directly to __init_subclass__. No metaclass is needed, and no metaclass conflicts can arise.

Here is a more advanced example that combines validation and registration using __init_subclass__:

copyclass Validator:
    """Mixin that enforces snake_case method names."""
    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        for name in vars(cls):
            if callable(getattr(cls, name)) and not name.startswith("_"):
                if name != name.lower():
                    raise NameError(
                        f"{cls.__name__}.{name} must be snake_case"
                    )

class Registrable:
    """Mixin that auto-registers subclasses."""
    _registry = {}

    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        Registrable._registry[cls.__name__] = cls

class BaseService(Validator, Registrable):
    pass

class UserService(BaseService):
    def create_user(self, name):
        return {"name": name}

    def delete_user(self, user_id):
        return {"deleted": user_id}

print(Registrable._registry)
# {'BaseService': ..., 'UserService': ...}

# This would raise NameError at class definition:
# class BadService(BaseService):
#     def createUser(self, name):  # not snake_case
#         pass

Both the validation and registration hooks run without any metaclass. If this same pattern required metaclasses, you would need to create a third metaclass that inherits from both validation and registration metaclasses, and resolve any conflicts in their __new__ methods manually.

__set_name__: The Other Half of PEP 487

PEP 487 introduced two hooks, not one. While __init_subclass__ handles subclass customization, __set_name__ solves a different metaclass dependency: descriptor initialization. Before Python 3.6, a descriptor had no way to know the attribute name it was assigned to in the class body unless a metaclass scanned the namespace and told it. This forced library authors to write metaclasses purely for descriptor bookkeeping. The __set_name__ hook eliminates that requirement entirely. For background on how descriptors work in Python, see the Python descriptor protocol reference:

copyclass ValidatedField:
    """Descriptor that enforces type checking using __set_name__."""
    def __set_name__(self, owner, name):
        self.name = name
        self.private_name = f"_{name}"

    def __get__(self, obj, objtype=None):
        if obj is None:
            return self
        return getattr(obj, self.private_name, None)

    def __set__(self, obj, value):
        if not isinstance(value, self.expected_type):
            raise TypeError(
                f"{self.name} expects {self.expected_type.__name__}, "
                f"got {type(value).__name__}"
            )
        setattr(obj, self.private_name, value)

class StringField(ValidatedField):
    expected_type = str

class IntField(ValidatedField):
    expected_type = int

class UserProfile:
    username = StringField()
    age = IntField()

    def __init__(self, username, age):
        self.username = username
        self.age = age

user = UserProfile("alice", 30)
print(user.username)  # alice

try:
    user.age = "thirty"
except TypeError as e:
    print(e)  # age expects int, got str

The __set_name__ method receives the owning class and the attribute name automatically when type.__new__ creates the class. Before this hook existed, the only way to achieve the same result was a metaclass that iterated over the namespace and called a custom initialization method on each descriptor. That pattern appeared in nearly every ORM and validation library. With __set_name__, the descriptor handles its own initialization and the metaclass becomes unnecessary for this purpose.

Framework Evolution: From Metaclasses to __init_subclass__

The shift away from metaclasses is not theoretical. SQLAlchemy 2.0 redesigned its declarative mapping system around __init_subclass__ instead of the DeclarativeMeta metaclass that powered earlier versions. The new DeclarativeBase class uses __init_subclass__ to set up mapped classes, eliminating the metaclass from the inheritance chain entirely. SQLAlchemy also provides DeclarativeBaseNoMeta specifically for users who need to combine declarative mapping with their own custom metaclasses without conflicts.

This migration pattern is instructive. SQLAlchemy's metaclass was responsible for scanning class attributes, registering mapped classes, and configuring table metadata. All of that registration and attribute processing now happens through __init_subclass__ and __set_name__. The metaclass was only truly necessary for the era before PEP 487 provided these hooks. Libraries and frameworks that still use metaclasses often do so for backward compatibility or because they need __prepare__ to intercept the class body namespace, which remains the one hook that only metaclasses can provide.

copyclass Descriptor:
    def __set_name__(self, owner, name):
        print(f"__set_name__ called: {owner.__name__}.{name}")
        self.name = name

class MyClass:       # __set_name__ fires HERE
    field = Descriptor()
# prints: __set_name__ called: MyClass.field

obj = MyClass()      # __set_name__ does NOT fire here

copy# type.__new__ does roughly this internally:
# for key, value in namespace.items():
#     if hasattr(value, '__set_name__'):
#         value.__set_name__(cls, key)

class TypedField:
    def __set_name__(self, owner, name):
        self.name = name              # now knows its own name
        self.storage = f"_{name}"     # can derive storage key

    def __set__(self, obj, value):
        setattr(obj, self.storage, value)

    def __get__(self, obj, objtype=None):
        return getattr(obj, self.storage, None) if obj else self

copy# Timeline of calls:
# 1. class MyClass:             -> body executes
# 2. type.__new__(...)          -> class object created
# 3. descriptor.__set_name__()  -> called by type.__new__
#    (descriptor now knows its name)
#
# ... much later ...
# 4. obj = MyClass()
# 5. obj.field                  -> descriptor.__get__() called
#    (name was set long ago in step 3)

Side-by-Side Comparison

The decision flowchart is straightforward. If you need to control the class namespace via __prepare__, override class-level __call__, or set read-only attributes during construction, use a metaclass. If you need automatic inheritance-based propagation but none of those lower-level hooks, use __init_subclass__. For everything else, a class decorator is the simplest and safest choice.

Key Takeaways

1. Class decorators operate after class creation and compose freely. Use them for wrapping methods, injecting attributes, implementing singletons, and any modification that does not require intercepting the class construction process itself.
2. Metaclasses operate during class creation and propagate through inheritance. Reserve them for controlling __prepare__, overriding __call__ for instance creation, validating class structure at import time, and setting read-only attributes that cannot be changed after construction.
3. __init_subclass__ and __set_name__ handle the majority of former metaclass use cases. Introduced together in Python 3.6 via PEP 487, they provide automatic subclass hooks, descriptor self-initialization, and keyword argument support through the class definition line. Both compose cleanly through multiple inheritance and avoid metaclass conflicts entirely.
4. The territory that exclusively requires metaclasses is shrinking. Python 3.7 eliminated __prepare__-based definition ordering (dicts are ordered by default), PEP 487 eliminated metaclass-based descriptor initialization and subclass registration, and major frameworks like SQLAlchemy 2.0 have migrated from metaclasses to __init_subclass__. The remaining metaclass-only use cases are __prepare__ namespace customization, __call__ interception, and setting attributes that become read-only after class creation.
5. Start with decorators, escalate to __init_subclass__, and resort to metaclasses only when necessary. Each step up the ladder adds power but also adds complexity and constraints. The simplest tool that solves the problem is the right one.

The vast majority of metaprogramming tasks in Python fall into the class decorator, __init_subclass__, or __set_name__ territory. The landscape has shifted significantly since Python 3.6: use cases that once demanded metaclasses now have simpler alternatives, and major frameworks have responded by migrating away from metaclass-based architectures. Metaclasses remain essential for the narrow set of problems that require __prepare__ namespace interception, __call__ control over instantiation, or modification of attributes that lock after class creation. Understanding all four tools -- decorators, __init_subclass__, __set_name__, and metaclasses -- and when each one belongs, is what separates metaprogramming that helps a codebase from metaprogramming that haunts it.

How to Choose Between Class Decorators, Metaclasses, and __init_subclass__

1. Identify what you need to modify. Determine whether you need to change a finished class (add methods, wrap methods, inject attributes) or intervene in how the class is constructed (control the namespace, intercept instantiation, set read-only attributes).
2. Start with a class decorator. If your modification operates on a finished class -- wrapping methods, adding attributes, enforcing constraints -- a class decorator is the simplest and safest choice. Decorators compose freely with @ stacking and never cause metaclass conflicts.
3. Escalate to __init_subclass__ if you need inheritance propagation. If the behavior must automatically apply to all subclasses without requiring each one to be individually decorated, define __init_subclass__ on the base class. It composes through multiple inheritance and accepts keyword arguments from the class definition line.
4. Use __set_name__ for descriptor self-initialization. If your use case involves descriptors that need to know their own attribute name, implement __set_name__ on the descriptor class. This eliminates the need for a metaclass to scan the namespace and initialize descriptors manually.
5. Resort to a metaclass only for __prepare__, __call__, or read-only attributes. If you need to customize the namespace dict used during class body execution (__prepare__), intercept instance creation at the metaclass level (__call__), or set attributes like __doc__ that become read-only after class creation, a metaclass is the only option.

Frequently Asked Questions

What is the difference between a Python class decorator and a metaclass?

A class decorator is a function that receives a fully constructed class object, modifies or replaces it, and returns it. A metaclass is a class whose instances are themselves classes, controlling the creation process before the class object exists. Decorators act after class creation; metaclasses act during creation.

When should I use a class decorator instead of a metaclass in Python?

Use a class decorator when you need to wrap or modify methods, inject attributes, enforce simple constraints, or implement patterns like singleton. Class decorators are composable (you can stack multiple decorators), simpler to write, and do not conflict with other metaclasses.

When is a metaclass the better choice over a class decorator?

Use a metaclass when you need to control the class creation process itself, such as customizing __prepare__ to change the class namespace, automatically propagating behavior to all subclasses through inheritance, overriding __call__ to intercept instance creation, or modifying read-only class attributes like __doc__ that cannot be changed after class creation.

Can __init_subclass__ replace metaclasses in Python?

In many cases, yes. Introduced in Python 3.6 via PEP 487, __init_subclass__ is a hook that runs when a class is subclassed. It handles common metaclass use cases like subclass registration and validation without the complexity of a full metaclass. It also composes naturally through multiple inheritance, unlike metaclasses which can conflict.

Can I use both a class decorator and a metaclass on the same class?

Yes. The metaclass runs first during class creation, and the decorator runs after the class object is returned. This can be useful when a framework mandates a specific metaclass (like Django ORM) and you want to apply additional modifications via a decorator on top.

What is __set_name__ and how does it replace metaclasses for descriptors?

__set_name__ is a descriptor protocol method introduced in Python 3.6 via PEP 487. It is called automatically when a descriptor is assigned to a class attribute during class creation, receiving the owning class and the attribute name. Before __set_name__, descriptors needed a metaclass to discover their own attribute names in the class body. This hook eliminates that metaclass dependency entirely.