`builtins.slice` should be generic

[randolf-scholz]

This is a port of https://github.com/python/typing/issues/159, which was closed as being out of scope, with https://github.com/srittau suggesting it maybe be more suitable for typeshed instead.

It would be useful to have slice being generic and allowing type hints a la

• slice[start_type, stop_type, step_type]
• slice[S, T] as shorthand for slice[S, S, T] or slice[S, T, Any]
• slice[T] as shorthand for slice[T, T, T] or slice[T, T, Any] or slice[Any, T, Any]
• slice as shorthand for slice[Any, Any, Any]

Syntax wise, I would advocate for the latter options slice[S, T]=slice[S, T, Any], slice[T]=slice[Any, T, Any] for the following reasons:

1. It resembles the regular usage of slice:
   • slice(x) = slice(None, x, None),
   • slice(a, b) = slice(a, b, None)
2. It has better compatible with datetime/timedelta variables, which might be a common use-case.
   • slice[datetime]=slice[datetime, datetime, datetime] would be an error, because `datetimes cannot be added, only timedeltas can be added to datetimes.

Real-world examples

• Datetime based slicing: Here, start and stop are datetime-like and step is timedelta-like (e.g. datetime.datetime / datetime.timedelta, numpy.datetime64/numpy.timedelta64 or pandas.Timestamp/pandas.Timedelta)
• Label based slicing via strings, for example, pandas allows something like frame.loc["2017-07-01":"2017-10-31"] for a DataFrame that is indexed by a DatetimeIndex, this will first convert the strings to datetime objects and then select all rows of the table that lie between the given dates.
• Similarly, one might want to select all rows of a table that lie between two float values.

[TeamSpen210]

An example of heterogeneous types (although a little cute) is to do obj["keyword": value], effectively producing keyword arguments.

[Gobot1234]

Related https://peps.python.org/pep-0696/#using-another-typevarlike-as-the-default which were my thoughts on the matter

[AlexWaygood]

Marking as deferred until and unless PEP-696 is accepted by the Steering Council and implemented by all major type checkers

[lorenzo-w]

Little status update:

• The Python typing council has recommended accepting PEP 696 last week, so the steering council will likely also accept it for upcoming Python 3.13
• Pyright has already implemented PEP 696 for use with typing_extensions
• Mypy is apparently still working on its support

[srittau]

Cf. #11422 for the feature tracker.