Zusammenfassung

Dieses PEP schlägt mehrere neue Funktionen für Vergleiche vor

• Erlaube separate Überladung von <, >, <=, >=, ==, !=, sowohl in Klassen als auch in C-Erweiterungen.
• Erlaube es jedem dieser überladenen Operatoren, etwas anderes als ein boolesches Ergebnis zurückzugeben.

Motivation

Die Hauptmotivation kommt von NumPy, deren Benutzer zustimmen, dass A<B ein Array von elementweisen Vergleichsergebnissen zurückgeben sollte; sie müssen dies derzeit als less(A,B) schreiben, da A<B nur ein boolesches Ergebnis zurückgeben oder eine Ausnahme auslösen kann.

Eine zusätzliche Motivation ist, dass Typen oft keine natürliche Ordnung haben, aber trotzdem auf Gleichheit verglichen werden müssen. Derzeit muss ein solcher Typ muss Vergleiche implementieren und damit eine willkürliche Ordnung definieren, nur damit die Gleichheit getestet werden kann.

Außerdem kann für einige Objekttypen ein Gleichheitstest viel effizienter implementiert werden als ein Ordnungstest; zum Beispiel sind Listen und Dictionaries, die sich in der Länge unterscheiden, ungleich, aber die Ordnung erfordert die Inspektion einiger (potenziell aller) Elemente.

Vorangegangene Arbeiten

Rich Comparisons wurden bereits vorgeschlagen; insbesondere von David Ascher, nach Erfahrungen mit Numerical Python

http://starship.python.net/crew/da/proposals/richcmp.html

Er ist auch unten als Anhang enthalten. Die meisten Materialien in diesem PEP stammen aus Davids Vorschlag.

Bedenken

1. Abwärtskompatibilität, sowohl auf Python-Ebene (Klassen, die __cmp__ verwenden, müssen nicht geändert werden) als auch auf C-Ebene (Erweiterungen, die tp_comparea definieren, müssen nicht geändert werden, Code, der PyObject_Compare() verwendet, muss auch dann funktionieren, wenn die verglichenen Objekte das neue Rich Comparison-Schema verwenden).
2. Wenn A<B eine Matrix elementweiser Vergleiche zurückgibt, ist ein einfacher Fehler, diesen Ausdruck in einem booleschen Kontext zu verwenden. Ohne spezielle Vorkehrungen wäre er immer wahr. Diese Verwendung sollte stattdessen eine Ausnahme auslösen.
3. Wenn eine Klasse x==y überschreibt, aber nichts anderes, sollte x!=y als not(x==y) berechnet werden oder fehlschlagen? Was ist mit der ähnlichen Beziehung zwischen < und >=, oder zwischen > und <=?
4. Ähnlich, sollten wir x<y aus y>x berechnen lassen? Und x<=y aus not(x>y)? Und x==y aus y==x, oder x!=y aus y!=x?
5. Wenn Vergleichsoperatoren elementweise Vergleiche zurückgeben, was ist mit Shortcut-Operatoren wie A<B<C, A<B and C<D, A<B or C<D?
6. Was ist mit min() und max(), den 'in' und 'not in' Operatoren, list.sort(), Dictionary-Schlüsselvergleich und anderen Verwendungen von Vergleichen durch eingebaute Operationen?

Vorgeschlagene Lösungen

1. Volle Abwärtskompatibilität kann wie folgt erreicht werden. Wenn ein Objekt tp_compare() definiert, aber nicht tp_richcompare(), und ein Rich Comparison angefordert wird, wird das Ergebnis von tp_compare() auf offensichtliche Weise verwendet. Z.B. wenn „<“ angefordert wird, wird eine Ausnahme ausgelöst, wenn tp_compare() eine Ausnahme auslöst, das Ergebnis ist 1, wenn tp_compare() negativ ist, und 0, wenn es null oder positiv ist. Usw.

   Volle Vorwärtskompatibilität kann wie folgt erreicht werden. Wenn ein klassischer Vergleich für ein Objekt angefordert wird, das tp_richcompare() implementiert, werden bis zu drei Vergleiche verwendet: zuerst wird == versucht, und wenn es wahr zurückgibt, wird 0 zurückgegeben; als nächstes wird < versucht und wenn es wahr zurückgibt, wird -1 zurückgegeben; als nächstes wird > versucht und wenn es wahr zurückgibt, wird +1 zurückgegeben. Wenn ein versuchter Operator einen nicht-booleschen Wert zurückgibt (siehe unten), wird die durch Konvertierung in Boolean ausgelöste Ausnahme weitergegeben. Wenn keiner der versuchten Operatoren wahr zurückgibt, werden als nächstes die klassischen Vergleichs-Fallbacks versucht.

   (Ich habe lange und intensiv über die Reihenfolge nachgedacht, in der die drei Vergleiche versucht werden sollten. An einem Punkt hatte ich ein überzeugendes Argument dafür, dies in dieser Reihenfolge zu tun, basierend auf dem Verhalten von Vergleichen für zyklische Datenstrukturen. Aber seit dieser Code wieder geändert wurde, bin ich mir nicht mehr so sicher, ob es einen Unterschied macht.)

2. Jeder Typ, der eine Sammlung von Booleans anstelle eines einzelnen Booleans zurückgibt, sollte nb_nonzero() definieren, um eine Ausnahme auszulösen. Ein solcher Typ wird als nicht-boolesch betrachtet.
3. Die Operatoren == und != werden nicht als gegenseitig komplementär angenommen (z. B. erfüllen IEEE 754 Gleitkommazahlen dies nicht). Es liegt am Typ, dies bei Bedarf zu implementieren. Ähnlich für < und >=, oder > und <=; es gibt viele Beispiele, bei denen diese Annahmen nicht zutreffen (z. B. tabnanny).
4. Die Reflexivitätsregeln werden von Python angenommen. Daher kann der Interpreter y>x mit x<y vertauschen, y>=x mit x<=y, und die Argumente von x==y und x!=y vertauschen. (Hinweis: Python nimmt derzeit an, dass x==x immer wahr und x!=x nie wahr ist; dies sollte nicht angenommen werden.)
5. Im aktuellen Vorschlag wird, wenn A<B ein Array von elementweisen Vergleichen zurückgibt, dieses Ergebnis als nicht-boolesch betrachtet, und seine Interpretation als boolesch durch die Shortcut-Operatoren löst eine Ausnahme aus. David Aschers Vorschlag versucht, dies zu behandeln; ich denke nicht, dass dies die zusätzliche Komplexität im Code-Generator wert ist. Anstelle von A<B<C kann man (A<B)&(B<C) schreiben.
6. Die Operationen min() und list.sort() werden nur den Operator < verwenden; max() wird nur den Operator > verwenden. Die Operatoren 'in' und 'not in' und die Dictionary-Suche werden nur den Operator == verwenden.

Implementierungsvorschlag

Dies folgt eng David Aschers Vorschlag.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.

Anhang

Hier ist der größte Teil von David Aschers ursprünglichem Vorschlag (Version 0.2.1, datiert Mi Jul 22 16:49:28 1998; ich habe die Abschnitte Inhaltsverzeichnis, Verlauf und Patches weggelassen). Er behandelt fast alle oben genannten Bedenken.

Zusammenfassung

Ein neuer Mechanismus, der es Vergleichen von Python-Objekten ermöglicht, Werte außer -1, 0 oder 1 zurückzugeben (oder Ausnahmen auszulösen), wird vorgeschlagen. Dieser Mechanismus ist vollständig abwärtskompatibel und kann auf der Ebene des C PyObject-Typs oder der Python-Klassendefinition gesteuert werden. Es gibt drei kooperierende Teile des vorgeschlagenen Mechanismus

• die Verwendung des letzten Slots in der Typobjektstruktur zur Speicherung eines Zeigers auf eine Rich Comparison-Funktion
• die Hinzufügung von speziellen Methoden für Klassen
• die Hinzufügung eines optionalen Arguments zur eingebauten cmp() Funktion.

Motivation

Das aktuelle Vergleichsprotokoll für Python-Objekte geht davon aus, dass zwei beliebige Python-Objekte verglichen werden können (seit Python 1.5 können Objektvergleiche Ausnahmen auslösen) und dass der Rückgabewert für jeden Vergleich -1, 0 oder 1 sein soll. -1 zeigt an, dass das erste Argument der Vergleichsfunktion kleiner ist als das rechte, +1 die kontrare positive, und 0, dass die beiden Objekte gleich sind. Während dieser Mechanismus die Festlegung einer Ordnungsbeziehung ermöglicht (z. B. für die Verwendung durch die sort() Methode von Listenobjekten), hat er sich im Kontext von Numeric Python (NumPy) als begrenzt erwiesen.

Insbesondere erlaubt NumPy die Erstellung mehrdimensionaler Arrays, die die meisten numerischen Operatoren unterstützen. Somit

x = array((1,2,3,4))        y = array((2,2,4,4))

sind zwei NumPy-Arrays. Während sie elementweise addiert werden können,

z = x + y   # z == array((3,4,7,8))

können sie im aktuellen Framework nicht verglichen werden – die veröffentlichte Version von NumPy vergleicht die Zeiger (wodurch fehlerhafte Informationen entstehen), was die einzige Lösung vor der kürzlichen Hinzufügung der Fähigkeit (in 1.5) war, Ausnahmen in Vergleichsfunktionen auszulösen.

Selbst mit der Fähigkeit, Ausnahmen auszulösen, macht das aktuelle Protokoll Array-Vergleiche nutzlos. Um dieser Tatsache Rechnung zu tragen, enthält NumPy mehrere Funktionen, die die Vergleiche durchführen: less(), less_equal(), greater(), greater_equal(), equal(), not_equal(). Diese Funktionen geben Arrays mit der gleichen Form wie ihre Argumente zurück (modulo Broadcasting), gefüllt mit 0en und 1en, je nachdem, ob der Vergleich für jedes Elementpaar wahr oder falsch ist. So zum Beispiel mit den oben definierten Arrays x und y

less(x,y)

wäre ein Array, das die Zahlen (1,0,0,0) enthält.

Der aktuelle Vorschlag ist, die Python-Objektschnittstelle zu ändern, damit das NumPy-Paket x < y das gleiche zurückgibt wie less(x,y). Der genaue Rückgabewert liegt beim NumPy-Paket – was dieser Vorschlag wirklich verlangt, ist die Änderung des Python-Kerns, damit Erweiterungsobjekte die Möglichkeit haben, etwas anderes als -1, 0, 1 zurückzugeben, wenn ihre Autoren dies wünschen.

Aktueller Stand der Dinge

Das aktuelle Protokoll besteht auf C-Ebene darin, dass jeder Objekttyp einen tp_compare Slot definiert, der ein Zeiger auf eine Funktion ist, die zwei PyObject* Referenzen entgegennimmt und -1, 0 oder 1 zurückgibt. Diese Funktion wird von der PyObject_Compare() Funktion aufgerufen, die in der C API definiert ist. PyObject_Compare() wird auch von der eingebauten Funktion cmp() aufgerufen, die zwei Argumente entgegennimmt.

x < y < z

temp1 = x < y
if temp1:
  return y < z
else:
  return temp1

x < y < z

temp1 = x < y
if temp1:
  temp2 = y < z
  return boolean_combine(temp1, temp2)
else:
  return temp1

def boolean_combine(a, b):
    if hasattr(a, '__boolean_and__') or \
       hasattr(b, '__boolean_and__'):
        try:
            return a.__boolean_and__(b)
        except:
            return b.__boolean_and__(a)
    else: # standard behavior
        if a:
            return b
        else:
            return 0