Annotations for Type factories

Context: at my company, we have a wildly used framework that at the time of writing didn't consider good static type hints for the framework users as one of the design objectives.

It makes use of the "type factory" pattern that could be illustrated with the following (much simplified) example

# framework code

# `make_int_in_range_class` is a "type factory" method
def make_int_in_range_class(lower: int, upper: int):
    # imagine here some very elaborated machinery that constructs the type dynamically
    class IntInRange(int):
        def __init__(self, v: int) -> None:
            if v < lower or v > upper:
                raise ValueError("not in range")
            self.v = v
        
        # many more methods like
        def custom_serialization() -> bytes:
            return b"foo"
    
    return IntInRange

# user code in another file

MyIntInRange = make_int_in_range_class(0, 10)  # Create the `MyIntInRange` Type

def foo(x: MyIntInRange) -> None:  # use `MyIntInRange` type in the annotation 
    print(x)

foo(MyIntInRange(4))  # example usage

When I run mypy on this code I'm rightfully getting

-----------------------------------------------------------------------------
demo.py: note: In function "foo":
demo.py:12:12: error: Variable
"robotypes_toy_generic.demo.MyIntInRange" is not valid as a type  [valid-type]
    def foo(x: MyIntInRange) -> None:
               ^
demo.py:12:12: note: See https://mypy.readthedocs.io/en/latest/common_issues.html#variables-vs-type-aliases
Found 1 error in 1 file (checked 1 source file)

Note that Pyright seems to be more permissive here and doesn't error out, but this seems to be a non-standard behavior from PEPs point of view.

The goal of having the type hint at the first place in this code is 2 fold:

1. Documentation.
2. We could not afford yet to enable globally the check_untyped_defs = True flag, too many errors. But I'd like to remove one obstacle from getting type check coverage in the new code, so it's desirable to have the type hints (however poor they could be). And I'd like to avoid having excessive use of Any or type: ignore[untyped-def].

Ideally, I'd like to have some syntax to tell any type checker that make_int_in_range_class produces a valid type (let's say even Any to make things simple, but maybe it could be some Protocol).

I was not able to find a good way of doing it short of asking ALL USERS to write some typing lie like

if TYPE_CHECKING:
  MyIntInRange = Any
else:
  MyIntInRange = make_int_in_range_class(0, 10)  # Create the `MyIntInRange` Type

This is kind of a sad solution and also we have something like 1000 call sites that would need to be updated like that.
So I'm looking for advice on how this could be addressed on the framework level OR if people think it's not too fringy, maybe we could add a new feature in typing for that.

I was imagining that it could be possible to make something like this work

def make_int_in_range_class() -> Type[Any]:

Das Issue nennt keine Repository-Datei und keinen Test; beginne mit dem vereinfachten type-factory-Beispiel und der mypy-Diagnose valid-type. Vergleiche die vorgeschlagene Type[Any]-Annotation mit dem im Issue beschriebenen Verhalten von typing und betrachte die Arbeit erst dann als abgeschlossen, wenn eine konkrete Änderung an der Typisierung oder eine dokumentierte Anleitung vereinbart wurde.