Return type of slice-aware __getitem__

[o11c]

This has been discussed before, but since this involves a language item, it is especially important, and it might be acceptable to special-case a solution.

Since @overload is not allowed in non-stubs, it's not clear how slicing should be implemented in user-defined containers.

In stubs, you can use:

class Foo(Generic[T]):
    @overload
    def __getitem__(self, i: int) -> T: ...
    @overload
    def __getitem__(self, s: slice) -> Foo[T]: ...

But in source files the best you can do is:

class Foo(Generic[T]):
    def __getitem__(self, i: Union[int, slice]) -> Union[T, List[T]]: ...

which will require unacceptable casts at every call site. (incidentally, slice should be a generic, not every use will be int).

And currently, it is difficult to mix some parts from a stub file and some not. I am currently investigating whether CRTP works though.

[JukkaL]

You may want to move this discussion to https://github.com/ambv/typehinting or python-ideas as this problem is not specific to mypy. However, we may be able to come up with a mypy-only workaround that doesn't need changes to typing. Also, this is similar to #885.

Here is a strawman proposal that doesn't require changes to typing (I'm not saying that this is a good one):

class Foo(Generitc[T]):
    def __getitem__(self, i: int) -> T:
        # overload-type: (slice) -> Foo[T]
        if isinstance(i, int):
            return ...
        else:
            return ... # slice case

This is a generalization of Python 2 signature comments (# type: (...) -> ...). Now __getitem__ would have two signatures and a single implementation. An obvious drawback is that this wouldn't be compatible with other PEP 484 compatible tools.

It's true that slice should probably be generic. Again, this should be discussed on typehinting. Do you want to open an issue there?

[o11c]

Added to python/typing#72 but leaving this open to discuss implementation possibilities.

Filed python/typing#159 for the slice[T] bit.

[JukkaL]

In python/typing#72 we are reaching consensus that having @overload decorated functions to 'declare' the signatures, followed by a regular function definition without annotations is a good way to do this.

[JelleZijlstra]

We now allow @overload outside of stubs, so this can be closed.