Map over types in a type-checker-friendly way

[robertmaxton42]

I'd like to type a generic, variadic map function; that is, something a type signature that looks something like

([*Ts] -> U)-> *map(Iterator, Ts) -> Iterator[U]

In fact I tried exactly that (first defining a "ClassCallable" that uses __new__ instead of __call__ so I could embed a lambda into a static type), but discovered that current type checkers don't allow call expressions in type signatures. Which I think is a great shame, given that Python already has so much machinery for dynamically creating and manipulating types, classes, and metaclasses, but oh well.

At any rate, I've been trying to find a way of "statically" defining that map at compile time, with no real success. Things I've tried:

• Overloading __class_getitem__ -- Type checkers don't honor it and give various complaints that boil down to "I tried to apply the standard Generic machinery and it didn't work" instead.
• Overloading __getitem__ on a metaclass -- Type checkers used to honor it (I think?), but don't anymore; same as above.
• Tricking the type checker by adding an unused Generic[T] to either of the above -- Removes one layer of red squiggly underlines, but now gives complaints of the form type[tuple[...]] is not iterable. Which I presume boils down to "type checkers do essentially no evaluation on type annotations", backed up with...
• Making a class with class variables that compute the tuple of types and referring to those -- I just get the type of the tuple of types again. This one mildly surprised me, but I guess that in Python creating a class is still a runtime thing, huh.

Any advice?

[Daverball]

This is not currently possible, you can take a look at what the type signatures for python's own map iterator in typeshed look like: https://github.com/python/typeshed/blob/main/stdlib/builtins.pyi#L1474-L1513

As you can see they add overloads for the most common cases i.e. 1 iterable, 2 iterables, 3 iterables, 4 iterables and 5 iterables and above they give up and fall back to non-type-safe overload that will accept anything that roughly matches the shape, without detecting incompatible signatures.

[Daverball]

Although I haven't really played around with TypeVarTuple yet, since mypy doesn't support it yet, but this still doesn't seem like a use-case that's supported by TypeVarTuple, since it's a non-trivial case of mutating each individual tuple element type, this sounds like it would require its own typing construct in order to work.

There is already an issue to support such mutations: #1216

[insilications]

I have the similar problem to #1216. Looking at the type signatures for python's own map iterator in typeshed look like, like @Daverball said... I simply gave up trying to use TypeVarTuple and just wrote several overloads cases. It is not worth the headache trying to hack it.