Jojain
May 21, 2025, 11:01am
9
Thanks @jorenham ,self that may open more solutions to this kind of problems in the future.
In my typing quest I have also encountered the same issue as @bryevdv and I ended up accepting that the only solution we currently have is the one provided by @Tinche but that is not fullfilling the goal completly.
As far as I know in Python type hinting the only way there is to properly do type mappings is on functions with the overload decorator. I have read some criticism about the verbosity of it on functions and I doesn’t solve the more general type mapping concept we have here.
Some links related to this idea:
opened 07:36PM - 15 Oct 22 UTC
topic: feature
(originally proposed here https://github.com/python/mypy/issues/13870 , but it t… urns out this is a better place to discuss)
**Feature**
Assume we have a mapping between types, possibly because there's a method with many overloads that takes an object from the first collection of types, and maps it into an object from the second collection of types.
Then, assume we have a generic class for which we have a `TypeVar` that corresponds with the first type. Then there is a method in this generic that does the transformation and produces a corresponding type.
Right now, it would be possible to type the outcome as a union, but much better would be to statically infer the output type.
```python
TypeLookupTable = TypeMapping('TypeLookupTable', {
FromType1: ToType1,
FromType2: ToType2,
FromType3: ToType3,
...
})
T = TypeVar('T', bound=any_type_present_as_a_key_in_that_lookup_table)
@dataclass
class SomeGeneric(Generic[T]):
data: T
def func(self) -> TypeLookupTable[T]:
# This function should produce an instance of the corresponding type of `T` in
# that lookup table.
def func2(self) -> ReturnTypeForFunctionCall[some_function, [T]]:
# This function returns an object for which the return type is
# inferred by looking at the overload of `some_function`
# when called with input `T`.
return some_function(self.data)
```
**Pitch**
I'm building a synchronous abstraction layer on top of an async library. This means every type from the async implementation will correspond to a type from the synchronous abstraction. There is one function `wrap` with tons of overloads that takes an async type and returns the corresponding sync type. (it also takes an `anyio.BlockingPortal`, but that's not relevant for this issue). There are many approaches for the implementation, the dictionary mapping being the easiest, because runtime introspection of the types in the dictionary is the easiest.
Right now, I can't come up with other examples for situations where it's useful, but I'm sure there are other cases where a generic class calls any of a collection of function overloads and where we want to infer the corresponding return type.
Among the two demonstrated approaches, (`ReturnTypeForFunctionCall` and `TypeLookupTable`), I'm mostly in favor of `TypeLookupTable`, because a collection of overloads can always be expressed using that lookup table. Something like:
```python
def function_with_many_overloads[T](data: T) -> TypeLookuptable[T]: ...
```
(That would expand to as many overloads as there are mapped types in that table.)
From the mypy issue, I understand that this would be very useful for Numpy too.
Possibly related thread: https://mail.python.org/archives/list/typing-sig@python.org/thread/VGBBY63CUV7LTBDIIXDPYK3OWTQTUN3Y/#KL3VLJDJM5WGLBXWUZHOZG5PMGY2MFWQ
I recently came about a situation in my code where, as mentioned here , I have a clear mapping between input and output types that occurs in many different places throughout my code, and updating that mapping is just infeasible.
I’m a huge supporter of type-hinting for Python, and would be willing to look into implementing this functionality (see link below - as a new user to this forum I’m only able to include 2 links). However, I’m not sure what the process is like.
What steps would need to b…