Type lookup table for generics.
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 20.6k
- Forks
- 3.3k
- PR merge metrics
- PR metrics pending
Description
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 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.
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:
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.)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by examining the proposed TypeLookupTable and ReturnTypeForFunctionCall forms and how they relate to Python generic TypeVars and overloaded functions. Use the wrap example as the motivating entry point; done requires a decided design for statically inferring corresponding return types, including its supported mapping and overload semantics.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100