How Can We Resolve __set_name__ Error Propagation and Non-Model Field Issues in Django's #27880 Update?

Hello everyone

I am working on #27880: Use __set_name__ to replace some usages of contribute_to_class and need to discuss a couple of potential issues with this change.

1. Error Propagation in typeobject’s __set_name__

Before Python 3.12 (55c99d9), any exception raised in typeobject’s __set_name__ was wrapped inside a RuntimeError. According to #27800 and my implementation in this PR, Fields, Managers, and Options are now included as attributes during the type.__new__() call in ModelBase. This creates a situation where the following code:

PYTHONCopied
class AutoFieldMixin:
    def __set_name__(self, cls, name):
        if cls._meta.auto_field:
            raise ValueError(
                "Model %s can't have more than one auto-generated field." % cls._meta.label
            )
        super().__set_name__(cls, name)
        cls._meta.auto_field = self

results in a RuntimeError being propagated along with the expected AttributeError. This causes the test below to fail in Python 3.10 and 3.11:

PYTHONCopied
class MultipleAutoFieldsTests(TestCase):
    def test_multiple_autofields(self):
        msg = (
            "Model invalid_models_tests.MultipleAutoFields can't have more "
            "than one auto-generated field."
        )
        with self.assertRaisesMessage(ValueError, msg):
            class MultipleAutoFields(models.Model):
                auto1 = models.AutoField(primary_key=True)
                auto2 = models.AutoField(primary_key=True)

I’m unsure how to best address this issue and would appreciate any insights or recommendations.

2. Handling __set_name__ in Non-Model Class Definitions

If a Field instance is used as an attribute in a non-model class—such as an output_field in a models.expressions.Func subclass—__set_name__ will be invoked upon class creation. This can lead to crashes because __set_name__ expects the class to have a _meta attribute, which non-model classes don’t possess.

In practice, Django uses output_field in custom expressions (e.g., in Func, F, and ExpressionWrapper), and most of these fields don’t override __set_name__, so they aren’t affected. However, for the few that do override __set_name__, we need to decide on an approach. My current solution involves adding a duck-typing check (i.e., verifying that _meta exists) in every Field subclass that overrides __set_name__ and is used in a non-model class.

I wonder:

1. Should this check be applied uniformly across all Field subclasses that override __set_name__ for consistency?
2. Or should the use of Fields in non-model classes be considered an undocumented or unsupported edge case, leaving management up to the user given its rarity?

Any alternative approaches, thoughts on documentation as an edge case, or suggestions on how to handle this would be very helpful!

Thanks.