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

Offen
  • Stimmt etwas nicht?
#15,526 6 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
python
Bereich
devtools

Rechercherichtung

Beginne beim generischen slice-Stub von typeshed und überprüfe die in #13008 besprochenen new-Annotationen zusammen mit der Alternative in #13007. Vergleiche die slice(42)-Beispiele des Issues mit den Typen von .start, .stop und .step; fertig ist die Aufgabe, wenn die Annotationen None bewahren und das gezeigte Type-Checking-Verhalten korrekt ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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?

Vorherrschende Sprache
Python
Sterne
5.1k
Forks
2.1k
Ø Merge
2 T. 7 Min.
Gemergte PRs (30 T.)
116

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus python/typeshed

Alle Issues in python/typeshed

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.