Strategie „Strict dictionary“

Diese Strategie erkennt an, dass __getitem__ besonders darin ist, nur ein Objekt zu akzeptieren, und die Natur dieses Objekts muss in seiner Spezifikation der Achsen eindeutig sein: es kann entweder nach Ordnung oder nach Name erfolgen. Als Ergebnis dieser Annahme ist im Beisein von Schlüsselwortargumenten die übergebene Entität ein Dictionary und alle Labels müssen angegeben werden.

C0. a[1]; a[1,2]      -> idx = 1; idx = (1, 2)
C1. a[Z=3]            -> idx = {"Z": 3}
C2. a[Z=3, R=4]       -> idx = {"Z": 3, "R": 4}
C3. a[1, Z=3]         -> raise SyntaxError
C4. a[1, Z=3, R=4]    -> raise SyntaxError
C5. a[1, 2, Z=3]      -> raise SyntaxError
C6. a[1, 2, Z=3, R=4] -> raise SyntaxError
C7. a[1, Z=3, 2, R=4] -> raise SyntaxError

Strategie „mixed dictionary“

Diese Strategie lockert die obige Einschränkung, um ein Dictionary mit sowohl Zahlen als auch Zeichenketten als Schlüssel zurückzugeben.

C0. a[1]; a[1,2]      -> idx = 1; idx = (1, 2)
C1. a[Z=3]            -> idx = {"Z": 3}
C2. a[Z=3, R=4]       -> idx = {"Z": 3, "R": 4}
C3. a[1, Z=3]         -> idx = { 0: 1, "Z": 3}
C4. a[1, Z=3, R=4]    -> idx = { 0: 1, "Z": 3, "R": 4}
C5. a[1, 2, Z=3]      -> idx = { 0: 1, 1: 2, "Z": 3}
C6. a[1, 2, Z=3, R=4] -> idx = { 0: 1, 1: 2, "Z": 3, "R": 4}
C7. a[1, Z=3, 2, R=4] -> idx = { 0: 1, "Z": 3, 2: 2, "R": 4}

Strategie „named tuple“

Gibt ein benanntes Tupel für idx anstelle eines Tupels zurück. Schlüsselwortargumente hätten offensichtlich ihren angegebenen Namen als Schlüssel, und positionale Argumente hätten einen Unterstrich gefolgt von ihrer Reihenfolge.

C0. a[1]; a[1,2]      -> idx = 1; idx = (_0=1, _1=2)
C1. a[Z=3]            -> idx = (Z=3)
C2. a[Z=3, R=2]       -> idx = (Z=3, R=2)
C3. a[1, Z=3]         -> idx = (_0=1, Z=3)
C4. a[1, Z=3, R=2]    -> idx = (_0=1, Z=3, R=2)
C5. a[1, 2, Z=3]      -> idx = (_0=1, _2=2, Z=3)
C6. a[1, 2, Z=3, R=4] -> (_0=1, _1=2, Z=3, R=4)
C7. a[1, Z=3, 2, R=4] -> (_0=1, Z=3, _1=2, R=4)
                      or (_0=1, Z=3, _2=2, R=4)
                      or raise SyntaxError

Der erforderliche Typname des benannten Tupels könnte Index oder der Name des Arguments in der Funktionsdefinition sein, er behält die Reihenfolge und ist leicht zu analysieren, indem das Attribut _fields verwendet wird. Er ist abwärtskompatibel, vorausgesetzt, dass C0 mit mehr als einem Eintrag nun ein benanntes Tupel anstelle eines einfachen Tupels übergibt.

Strategie „New argument contents“

In der aktuellen Implementierung werden, wenn viele Argumente an __getitem__ übergeben werden, diese in einem Tupel gruppiert und dieses Tupel wird an __getitem__ als einzelnes Argument idx übergeben. Diese Strategie behält die aktuelle Signatur bei, erweitert aber den Variationsbereich in Typ und Inhalt von idx auf komplexere Darstellungen.

Wir identifizieren vier mögliche Wege, diese Strategie zu implementieren.

• P1: verwendet ein einzelnes Dictionary für die Schlüsselwortargumente.
• P2: verwendet einzelne Dictionaries mit jeweils einem Element.
• P3: ähnlich wie P2, ersetzt aber einzelne Dictionaries durch ein (key, value)-Tupel.
• P4: ähnlich wie P2, verwendet aber ein spezielles und zusätzliches neues Objekt: keyword()

Einige dieser Möglichkeiten führen zu degenerierten Notationen, d.h. ununterscheidbar von einer bereits möglichen Darstellung. Wieder einmal wird die vorgeschlagene Notation zu syntaktischem Zucker für diese Darstellungen.

Unter dieser Strategie bleibt das alte Verhalten für C0 unverändert.

C0: a[1]        -> idx = 1                    # integer
    a[1,2]      -> idx = (1,2)                # tuple

In C1 können wir entweder ein Dictionary oder ein Tupel verwenden, um Schlüssel und Wertpaar für den spezifischen Indizierungseintrag darzustellen. Wir müssen ein Tupel mit einem Tupel in C1 haben, da wir sonst a["Z", 3] nicht von a[Z=3] unterscheiden können.

C1: a[Z=3]      -> idx = {"Z": 3}             # P1/P2 dictionary with single key
                or idx = (("Z", 3),)          # P3 tuple of tuples
                or idx = keyword("Z", 3)      # P4 keyword object

Wie Sie sehen können, implizieren die Notationen P1/P2, dass a[Z=3] und a[{"Z": 3}] __getitem__ mit genau demselben Wert aufrufen und daher syntaktischer Zucker für letzteres sind. Die gleiche Situation tritt, wenn auch mit einem anderen Index, für P3 auf. Die Verwendung eines Schlüsselwortobjekts wie in P4 würde diese Degeneration beseitigen.

Für den C2-Fall

C2. a[Z=3, R=4] -> idx = {"Z": 3, "R": 4}     # P1 dictionary/ordereddict
                or idx = ({"Z": 3}, {"R": 4}) # P2 tuple of two single-key dict
                or idx = (("Z", 3), ("R", 4)) # P3 tuple of tuples
                or idx = (keyword("Z", 3),
                          keyword("R", 4) )   # P4 keyword objects

P1 bildet sich natürlich auf das traditionelle **kwargs-Verhalten ab, bricht aber die Konvention, dass zwei oder mehr Einträge für den Index ein Tupel ergeben. P2 behält dieses Verhalten bei und bewahrt zusätzlich die Reihenfolge. Das Beibehalten der Reihenfolge wäre auch mit einem OrderedDict möglich, wie in PEP 468 entworfen.

Die verbleibenden Fälle werden hier gezeigt.

C3. a[1, Z=3]   -> idx = (1, {"Z": 3})                     # P1/P2
                or idx = (1, ("Z", 3))                     # P3
                or idx = (1, keyword("Z", 3))              # P4

C4. a[1, Z=3, R=4] -> idx = (1, {"Z": 3, "R": 4})          # P1
                   or idx = (1, {"Z": 3}, {"R": 4})        # P2
                   or idx = (1, ("Z", 3), ("R", 4))        # P3
                   or idx = (1, keyword("Z", 3),
                                keyword("R", 4))           # P4

C5. a[1, 2, Z=3]   -> idx = (1, 2, {"Z": 3})               # P1/P2
                   or idx = (1, 2, ("Z", 3))               # P3
                   or idx = (1, 2, keyword("Z", 3))        # P4

C6. a[1, 2, Z=3, R=4] -> idx = (1, 2, {"Z":3, "R": 4})     # P1
                      or idx = (1, 2, {"Z": 3}, {"R": 4})  # P2
                      or idx = (1, 2, ("Z", 3), ("R", 4))  # P3
                      or idx = (1, 2, keyword("Z", 3),
                                      keyword("R", 4))     # P4

C7. a[1, Z=3, 2, R=4] -> idx = (1, 2, {"Z": 3, "R": 4})    # P1. Pack the keyword arguments. Ugly.
                      or raise SyntaxError                 # P1. Same behavior as in function calls.
                      or idx = (1, {"Z": 3}, 2, {"R": 4})  # P2
                      or idx =  (1, ("Z", 3), 2, ("R", 4)) # P3
                      or idx =  (1, keyword("Z", 3),
                                 2, keyword("R", 4))       # P4

Strategie „kwargs argument“

Akzeptiert ein optionales **kwargs-Argument, das nur Schlüsselwort sein sollte. idx wird ebenfalls optional, um einen Fall zu unterstützen, in dem keine nicht-schlüsselwort Argumente erlaubt sind. Die Signatur wäre dann entweder

__getitem__(self, idx)
__getitem__(self, idx, **kwargs)
__getitem__(self, **kwargs)

Angewendet auf unsere Fälle würde ergeben

C0. a[1,2]            -> idx=(1,2);  kwargs={}
C1. a[Z=3]            -> idx=None ;  kwargs={"Z":3}
C2. a[Z=3, R=4]       -> idx=None ;  kwargs={"Z":3, "R":4}
C3. a[1, Z=3]         -> idx=1    ;  kwargs={"Z":3}
C4. a[1, Z=3, R=4]    -> idx=1    ;  kwargs={"Z":3, "R":4}
C5. a[1, 2, Z=3]      -> idx=(1,2);  kwargs={"Z":3}
C6. a[1, 2, Z=3, R=4] -> idx=(1,2);  kwargs={"Z":3, "R":4}
C7. a[1, Z=3, 2, R=4] -> raise SyntaxError # in agreement to function behavior

Leere Indizierung a[] bleibt natürlich ungültige Syntax.

Verwende eine Methode

Man könnte die Indizierung so belassen, wie sie ist, und eine traditionelle get()-Methode für Fälle verwenden, in denen die einfache Indizierung nicht ausreicht. Dies ist ein guter Punkt, aber wie bereits in der Einleitung erwähnt, haben Methoden ein anderes semantisches Gewicht als die Indizierung, und man kann Slices nicht direkt in Methoden verwenden. Vergleichen Sie z.B. a[1:3, Z=2] mit a.get(slice(1,3), Z=2).

Die Autoren erkennen dieses Argument jedoch als zwingend an, und der Vorteil der semantischen Ausdruckskraft einer schlüsselwortbasierten Indizierung mag durch eine selten genutzte Funktion, die keinen ausreichenden Nutzen bringt und eine begrenzte Akzeptanz haben könnte, aufgewogen werden.

Emuliere das angeforderte Verhalten durch Missbrauch des Slice-Objekts

Diese äußerst kreative Methode nutzt das Verhalten von Slice-Objekten, vorausgesetzt, man akzeptiert die Verwendung von Zeichenketten (oder instanziiert ordnungsgemäß benannte Platzhalterobjekte für die Schlüssel) und akzeptiert die Verwendung von „:“ anstelle von „=“.

>>> a["K":3]
slice('K', 3, None)
>>> a["K":3, "R":4]
(slice('K', 3, None), slice('R', 4, None))
>>>

Obwohl eindeutig raffiniert, erlaubt dieser Ansatz keine einfache Abfrage des Schlüssel/Wert-Paares, ist zu clever und esoterisch und erlaubt keine Übergabe eines Slices wie in a[K=1:10:2].

Tim Delaney kommentiert jedoch

„Ich denke wirklich, dass a[b=c, d=e] einfach nur syntaktischer Zucker für a['b':c, 'd':e] sein sollte. Es ist einfach zu erklären und bietet die größte Rückwärtskompatibilität. Insbesondere Bibliotheken, die Slices bereits auf diese Weise missbraucht haben, werden mit der neuen Syntax weiterhin funktionieren.“

Wir glauben, dass dieses Verhalten zu unbequemen Ergebnissen führen würde. Die Bibliothek Pandas verwendet Zeichenketten als Bezeichnungen und erlaubt Notationen wie

>>> a[:, "A":"F"]

um Daten aus Spalte „A“ bis Spalte „F“ zu extrahieren. Gemäß dem obigen Kommentar würde diese Notation gleichermaßen erhalten mit

>>> a[:, A="F"]

was seltsam ist und mit der beabsichtigten Bedeutung von Schlüsselwörtern bei der Indizierung kollidiert, nämlich der Spezifizierung der Achse durch konventionelle Namen anstelle von Positionen.

Übergib ein Dictionary als zusätzlichen Index

>>> a[1, 2, {"K": 3}]

Diese Notation, obwohl weniger elegant, kann bereits verwendet werden und erzielt ähnliche Ergebnisse. Es ist offensichtlich, dass die vorgeschlagene Strategie „New argument contents“ als syntaktischer Zucker für diese Notation interpretiert werden kann.

Relevanz der Reihenfolge von Schlüsselwortargumenten

Im Rahmen der Diskussion dieses PEP ist es wichtig zu entscheiden, ob die Reihenfolgeinformation der Schlüsselwortargumente wichtig ist und ob Indizes und Schlüssel beliebig geordnet werden können (z.B. a[1,Z=3,2,R=4]). PEP 468 versucht, den ersten Punkt anzugehen, indem die Verwendung eines ordereddict vorgeschlagen wird, aber man wäre geneigt zu akzeptieren, dass Schlüsselwortargumente bei der Indizierung äquivalent zu kwargs bei Funktionsaufrufen sind und daher heute ebenso ungeordnet sind und die gleichen Einschränkungen haben.

Bedarf an Homogenität des Verhaltens

Im Verhältnis zur Strategie „New argument contents“ weist ein Kommentar von Ian Cordasco darauf hin, dass

„wäre es unzumutbar, wenn nur eine Methode sich völlig anders verhält als das Standardverhalten in Python. Es wäre verwirrend, wenn nur __getitem__ (und angeblich auch __setitem__) Schlüsselwortargumente akzeptiert, diese aber anstatt in ein Dictionary umzuwandeln, in einzelne Dictionaries mit einem Element umwandelt.“ Wir stimmen seinem Punkt zu; es muss jedoch darauf hingewiesen werden, dass __getitem__ in Bezug auf übergebene Argumente bereits in gewisser Weise besonders ist.

Chris Angelico erklärt ebenfalls

„es erscheint sehr seltsam, damit zu beginnen, zu sagen „hier, geben wir der Indizierung die Option, Schlüsselwort-Args zu tragen, genau wie bei Funktionsaufrufen“, und dann zurückzukommen und zu sagen „oh, aber anders als bei Funktionsaufrufen, sind sie inhärent geordnet und werden ganz anders getragen.““ Dem stimmen wir auch zu. Die geradlinigste Strategie, die Homogenität zu wahren, wäre die Strategie „kwargs argument“, die ein **kwargs-Argument für __getitem__ öffnet.

Einer der Autoren (Stefano Borini) meint, dass nur die „strict dictionary“-Strategie implementierungswürdig ist. Sie ist eindeutig, einfach, zwingt keine komplexen Parsings auf und löst das Problem der Referenzierung von Achsen entweder nach Position oder nach Namen. Der Anwendungsfall „Options“ wird wahrscheinlich besser mit einem anderen Ansatz gehandhabt und ist für diesen PEP möglicherweise irrelevant. Die alternative „named tuple“ ist eine weitere valide Wahl.

Verschwinden von .get() für Indizierung mit Standardfallback

Die Einführung eines „default“-Schlüsselworts könnte dict.get() obsolet machen, was durch d["key", default=3] ersetzt würde. Chris Angelico erklärt jedoch

„Derzeit müssen Sie __getitem__ (das eine Ausnahme auslöst, wenn ein Problem gefunden wird) plus etwas anderes schreiben, z.B. get(), das stattdessen einen Standardwert zurückgibt. Mit Ihrem Vorschlag würden beide Zweige innerhalb von __getitem__ gehen, was bedeutet, dass sie Code teilen könnten; aber es müssen immer noch zwei Zweige existieren.“

Zusätzlich fährt Chris fort

„Es wird eine Ad-hoc- und ziemlich willkürliche Pfütze von Namen geben (einige werden default= verwenden, andere werden sagen, das ist viel zu lang und gehen zu def=, außer dass das ein Schlüsselwort ist, also werden sie dflt= oder etwas Ähnliches verwenden...), es sei denn, es gibt eine starke Kraft, die die Leute zu einem einheitlichen Namen drängt.“.

Dieses Argument ist gültig, aber es ist gleichermaßen gültig für jeden Funktionsaufruf und wird im Allgemeinen durch etablierte Konventionen und Dokumentation behoben.

Zur Degeneration der Notation

Benutzer Drekin kommentierte: „Der Fall a[Z=3] und a[{"Z": 3}] ähnelt dem aktuellen a[1, 2] und a[(1, 2)]. Auch wenn man argumentieren könnte, dass die Klammern tatsächlich nicht Teil der Tupelnotation sind, sondern nur wegen der Syntax benötigt werden, mag es als Degeneration der Notation im Vergleich zum Funktionsaufruf erscheinen: f(1, 2) ist nicht dasselbe wie f((1, 2)).“.