How to type a m2m_changer receiver function

[Alexerson]

Hello,

I’m trying to type my receiver for a m2m_changed signal.

So far I have this:

models.py

from django.db import models


class Topping(models.Model):
    pass


class Pizza(models.Model):
    toppings = models.ManyToManyField(Topping, blank=True)

apps.py

from typing import TYPE_CHECKING, Literal, overload, reveal_type
from django.apps import AppConfig
from django.db.models.signals import m2m_changed

if TYPE_CHECKING:
    from .models import Pizza, Topping
    from django.db.models import Model


def my_callback(
    sender: "type[Model]",
    *,
    instance: "Pizza | Topping",
    action: Literal[
        "pre_add", "post_add", "pre_remove", "post_remove", "pre_clear", "post_clear"
    ],
    reverse: bool,
    model: "type[Pizza] | type[Topping]",
    pk_set: set[int],
    using: str,
) -> None:
    pass


class CoreConfig(AppConfig):
    default_auto_field = "django.db.models.BigAutoField"
    name = "core"

    def ready(self) -> None:
        from .models import Pizza

        reveal_type(Pizza.toppings.through)

        m2m_changed.connect(my_callback, sender=Pizza.toppings.through)

Is there any way to do better for the type hint of sender?
If I’m setting "type[Pizza.toppings.through]", I’m getting this error:
error: Name "Pizza.toppings.through" is not defined [name-defined]
Do we have an available generic for this?
reveal_type gives me "type[core.models.Pizza_toppings]".

Also, is there any way to use overload to improve this?
Like

@overload
def my_callback(
    sender: "type[Model]",
    *,
    instance: "Pizza",
    action: Literal[
        "pre_add", "post_add", "pre_remove", "post_remove", "pre_clear", "post_clear"
    ],
    reverse: Literal[False],
    model: "type[Topping]",
    pk_set: set[int],
    using: str,
): ...


@overload
def my_callback(
    sender: "type[Model]",
    *,
    instance: "Topping",
    action: Literal[
        "pre_add", "post_add", "pre_remove", "post_remove", "pre_clear", "post_clear"
    ],
    reverse: Literal[True],
    model: "type[Pizza]",
    pk_set: set[int],
    using: str,
): ...

But then, in the function, it obviously doesn’t work:

    if not reverse:
        reveal_type(instance)
        reveal_type(model)
    else:
        reveal_type(instance)
        reveal_type(model)

will give

apps.py:53: note: Revealed type is "Union[core.models.Pizza, core.models.Topping]"
apps.py:54: note: Revealed type is "Union[type[core.models.Pizza], type[core.models.Topping]]"
apps.py:56: note: Revealed type is "Union[core.models.Pizza, core.models.Topping]"
apps.py:57: note: Revealed type is "Union[type[core.models.Pizza], type[core.models.Topping]]"

Maybe simply using typing.cast then?

    if not reverse:
        instance = cast("Pizza", instance)
        model = cast("type[Topping]", model)
    else:
        instance = cast("Topping", instance)
        model = cast("type[Pizza]", model)

Anyway, mostly me ranting, but I’m curious if anyone have ideas about that.

[flaeppe]

Yes, there is a way to use a type for the through model. You need to declare and (since it's declared you might as well just) use the through model.

from django.db import models


class Topping(models.Model):
    pass


+class PizzaTopping(models.Model):
+    topping = models.ForeignKey(Topping, on_delete=models.CASCADE)
+    pizza = models.ForeignKey("app.Pizza", on_delete=models.CASCADE)
+    
+    class Meta:
+        constraints = [models.UniqueConstraint(fields=["topping", "pizza"], name="topping_pizza_unq")]
+
+
class Pizza(models.Model):
-    toppings = models.ManyToManyField(Topping, blank=True)
+    toppings = models.ManyToManyField(Topping, blank=True, through=PizzaTopping)

[Alexerson]

Ah, yeah, I guess that’s a way to do it, clever. Thanks!

[flaeppe]

And regarding

Also, is there any way to use overload to improve this?

Not really, since overloading is for the caller side. But the caller in this case is Django internals. So unless you write code that calls the receiver function an overload won't help you

[Alexerson]

Yeah, exactly. I was more trying to explain what I was doing. But in that case, the cast is probably good enough.