Adam Johnson

> Can't we restrict these to combinables and types that are valid as database bind variables for example? Something like `int | str | UUID | ... | Combinable |...

> Maybe this is a controversial opinion, but honestly my preference would be to use `# type: ignore` in these special cases involving nonstandard types, and get the benefit of...

I like it. Shall we do the same here? How would we find which `Any`s need to be `Incomplete` ?

Sorry, I left this til now. Yeah, you're right, let's be strict for now until there are issues and fix those more concretely.

That said, I'm not quite sure how to proceed here. I couldn't find clear evidence of which types to accept for some functions, e.g. `Replace`, where the old types are...

I'd like to make some hints conditional by Django version, if that could be possible... perhaps the mypy plugin could provide the current version?

I was thinking about typing `django.VERSION` conditionally, so we could use the same syntax as at runtime: ```py if django.VERSION >= (4 ,1): ... # new stuff else: ... #...

> So you could possibly construct something very verbose to achieve this by exposing major and minor versions as independent variables and thrashing out all combinations. We could also use...

I opened an issue about conditional types based on Django version: #1244

/submit