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:
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:
- it's error-prone / less ergonomic
- it renders part of #13008
__new__ overloading complexity superfluous
- it made #13007 more complex
Question
@Sachaa-Thanasius: Was the proposed solution considered for #13007?
Situation
#13008 made
slice.__new__more precise. Genericslice[T]acceptsT | Noneas arguments when creating aslice.However, properties
.start,.stop,. stepof (generic)slice[...]are typed as there respective types, i.e.Tin above example.Consequence
This leads to typecheckers accepting:
whereas below obviously breaks:
Solution
Therefore, I suggest properties
.start,.stop,. stepshould have optional (| None) return types:Alternative
Currently,
typeshedusesslice[...]asslice[T | None]explicitly as per #13007, e.g.While that works/typechecks correctly:
I see as downsides:
__new__overloading complexity superfluousQuestion
@Sachaa-Thanasius: Was the proposed solution considered for #13007?