Properties `.start`, `.stop`, `. step` of (generic) `slice[...]` should be optional (`| None`)

[Dutcho]

Situation

#13008 made slice.__new__ more precise. Generic slice[T] accepts T | None as arguments when creating a slice.
However, properties .start, .stop, . step of (generic) slice[...] are typed as there respective types, i.e. T in above example.

Consequence

This leads to typecheckers accepting:

def test(s: slice[int]) -> None:
    assert_type(s.start, int)
    if s.start is None:
        assert_never(s.start)

whereas below obviously breaks:

test(slice(42))

Solution

Therefore, I suggest properties .start, .stop, . step should have optional (| None) return types:

    @property
    def start(self) -> _StartT_co | None: ...
    @property
    def step(self) -> _StepT_co | None: ...
    @property
    def stop(self) -> _StopT_co | None: ...

Alternative

Currently, typeshed uses slice[...] as slice[T | None] explicitly as per #13007, e.g.

class str:
    def __getitem__(self, key: SupportsIndex | slice[SupportsIndex | None], /) -> str: ...

While that works/typechecks correctly:

def test(s: slice[int | None]) -> None:
    assert_type(s.start, int | None)
    if s.start is None or isinstance(s.start, int):
        pass
    else:
        assert_never(s.start)

test(slice(42))   # okay
test(slice('x'))  # error: Argument 1 to "slice" has incompatible type "str"; expected "int | None"  [arg-type]

I see as downsides:

1. it's error-prone / less ergonomic
2. it renders part of #13008 __new__ overloading complexity superfluous
3. it made #13007 more complex

Question

@Sachaa-Thanasius: Was the proposed solution considered for #13007?

[srittau]

I'm unsure why we're using Any instead of None for the return type annotations of slice.__new__. The comment says:

Note: new overloads map None to Any, since users expect slice(x, None) to be compatible with slice(None, x).

But I'm not sure what that means.

[srittau]

Cc @randolf-scholz

[randolf-scholz]

Using T | None for start/stop/step was my initial instinct as well, but there were cases in mypy primer that got hit by that: #12899 (comment)

See for example this commit: 3010eda

and the mypy primer output: #12899 (comment)

If we make None implicit, this means we force every user of slices to accept open-ended slice, but there are users who seem to rely on only using bounded slices in some cases, for example, code like this in xarray: (https://github.com/pydata/xarray/blob/a1c0617051260cc84789bfc6c31a7fef3d64f01b/xarray/core/indexing.py#L318
)

def slice_slice(old_slice: slice, applied_slice: slice, size: int) -> slice:
    """Given a slice and the size of the dimension to which it will be applied,
    index it with another slice to return a new slice equivalent to applying
    the slices sequentially
    """
    old_slice = slice(*old_slice.indices(size))

    size_after_old_slice = len(range(old_slice.start, old_slice.stop, old_slice.step))
    if size_after_old_slice == 0:
        # nothing left after applying first slice
        return slice(0)

    applied_slice = slice(*applied_slice.indices(size_after_old_slice))

    start = old_slice.start + applied_slice.start * old_slice.step
    if start < 0:
        # nothing left after applying second slice
        # (can only happen for old_slice.step < 0, e.g. [10::-1], [20:])
        return slice(0)

    stop = old_slice.start + applied_slice.stop * old_slice.step
    if stop < 0:
        stop = None

    step = old_slice.step * applied_slice.step

    return slice(start, stop, step)

[randolf-scholz]

I'm unsure why we're using Any instead of None for the return type annotations of slice.new. The comment says:

This was a result of this discussion: #12899 (comment)