Antwort

Es gibt Präzedenzfälle für nicht-kommutative Vereinigungen in Python

>>> {0} | {False}
{0}
>>> {False} | {0}
{False}

Während die Ergebnisse gleich sein mögen, sind sie deutlich unterschiedlich. Im Allgemeinen ist a | b nicht dieselbe Operation wie b | a.

Antwort

Das gleiche Argument gilt für die Sequenzverkettung.

Die Sequenzverkettung wächst mit der Gesamtzahl der Elemente in den Sequenzen, was zu einer O(N**2) (quadratischen) Leistung führt. Die Dict-Vereinigung wird wahrscheinlich doppelte Schlüssel beinhalten, sodass die temporären Mappings nicht so schnell wachsen werden.

So wie es selten ist, dass Leute große Mengen von Listen oder Tupeln verketten, glauben die Autoren dieser PEP, dass es selten sein wird, dass Leute große Mengen von Dictionaries zusammenführen. collections.Counter ist eine Dict-Unterklasse, die viele Operatoren unterstützt, und es sind keine Beispiele bekannt, bei denen Leute Leistungsprobleme aufgrund der Kombination großer Mengen von Counter hatten. Darüber hinaus hat eine Untersuchung der Standardbibliothek durch die Autoren keine Beispiele für die Zusammenführung von mehr als zwei Dictionaries gefunden, sodass dies wahrscheinlich kein Leistungsproblem in der Praxis ist… „Alles ist schnell genug für kleine N“.

Wenn man erwartet, eine große Anzahl von Dictionaries zusammenzuführen, bei denen die Leistung wichtig ist, ist es möglicherweise besser, eine explizite Schleife und In-Place-Zusammenführung zu verwenden.

new = {}
for d in many_dicts:
    new |= d

Antwort

Es ist nicht klar, warum der erste Teil dieses Arguments ein Problem ist. dict.update() kann Werte verwerfen, aber keine Schlüssel; das ist erwartetes Verhalten und wird es auch bleiben, unabhängig davon, ob es als update() oder | geschrieben wird.

Andere Arten der Vereinigung sind ebenfalls verlustbehaftet, im Sinne der Nicht-Umkehrbarkeit; Sie können die beiden Operanden nicht erhalten, wenn Sie nur die Vereinigung haben. a | b == 365… was sind a und b?

Antwort

Es gibt kein solches Koan. „Nur ein Weg“ ist eine Verleumdung über Python, die lange Zeit aus der Perl-Community stammt.

Antwort

Es gibt kein solches Verbot. Der „Zen of Python“ drückt lediglich eine *Präferenz* für „einen offensichtlichen Weg“ aus.

There should be one-- and preferably only one --obvious way to do
it.

Die Betonung liegt hier darauf, dass es einen offensichtlichen Weg geben sollte, „es“ zu tun. Im Falle von Dict-Update-Operationen gibt es mindestens zwei verschiedene Operationen, die wir möglicherweise durchführen möchten

• Ein Dict direkt aktualisieren: Der offensichtliche Weg ist die Verwendung der update()-Methode. Wenn dieser Vorschlag angenommen wird, funktioniert auch der erweiterte Zuweisungsoperator |=, aber das ist ein Nebeneffekt, wie erweiterte Zuweisungen definiert sind. Welchen Sie wählen, ist Geschmackssache.
• Zwei vorhandene Dictionaries zu einem dritten, neuen Dictionary zusammenführen: Diese PEP schlägt vor, dass der offensichtliche Weg die Verwendung des Fusionsoperators | ist.

In der Praxis wird diese Präferenz für „nur einen Weg“ in Python häufig verletzt. Zum Beispiel könnte jede for-Schleife als while-Schleife neu geschrieben werden; jeder if-Block könnte als if/else-Block geschrieben werden. Listen-, Mengen- und Dict-Comprehensions könnten alle durch Generatorausdrücke ersetzt werden. Listen bieten nicht weniger als fünf Möglichkeiten zur Durchführung von Verkettungen.

• Verkettungsoperator: a + b
• In-Place-Verkettungsoperator: a += b
• Slice-Zuweisung: a[len(a):] = b
• Sequenz-Unpacking: [*a, *b]
• Extend-Methode: a.extend(b)

Wir sollten nicht zu streng sein, wenn es darum geht, nützliche Funktionalität abzulehnen, nur weil sie gegen „nur einen Weg“ verstößt.

Antwort

Das ist sehr wahr. Aber es gilt heute genauso, wo die Verwendung des Operators | bedeuten könnte

• Bitweise OR für int/bool
• Vereinigung von set/frozenset
• jede andere überladene Operation

Das Hinzufügen der Dict-Vereinigung zur Menge der Möglichkeiten macht das Verstehen von Code nicht *schwieriger*. Es ist nicht mehr Arbeit erforderlich, um festzustellen, dass spam und eggs Mappings sind, als es dauern würde, festzustellen, dass sie Mengen oder ganze Zahlen sind. Und gute Namenskonventionen helfen.

flags |= WRITEABLE  # Probably numeric bitwise-or.
DO_NOT_RUN = WEEKENDS | HOLIDAYS  # Probably set union.
settings = DEFAULT_SETTINGS | user_settings | workspace_settings  # Probably dict union.

Antwort

Diese PEP nimmt keine Stellung dazu, ob Dictionaries die volle Sammlung von Mengenoperatoren unterstützen sollten, und würde dies lieber für eine spätere PEP aufheben (einer der Autoren ist daran interessiert, eine solche PEP zu entwerfen). Zum Nutzen jeder späteren PEP folgt eine kurze Zusammenfassung.

Die symmetrische Mengendifferenz (^) ist offensichtlich und natürlich. Zum Beispiel, gegeben zwei Dictionaries

d1 = {"spam": 1, "eggs": 2}
d2 = {"ham": 3, "eggs": 4}

wäre die symmetrische Differenz d1 ^ d2 {"spam": 1, "ham": 3}.

Die Mengendifferenz (-) ist ebenfalls offensichtlich und natürlich, und eine frühere Version dieser PEP enthielt sie im Vorschlag. Bei den obigen Dictionaries hätten wir d1 - d2 als {"spam": 1} und d2 - d1 als {"ham": 3}.

Die Mengen-Schnittmenge (&) ist etwas problematischer. Während es einfach ist, die Schnittmenge der *Schlüssel* in zwei Dictionaries zu ermitteln, ist nicht klar, was mit den *Werten* geschehen soll. Bei den beiden obigen Dictionaries ist offensichtlich, dass der einzige Schlüssel von d1 & d2 "eggs" sein muss. „Zuletzt gesehen gewinnt“ hat jedoch den Vorteil der Konsistenz mit anderen Dict-Operationen (und den vorgeschlagenen Union-Operatoren).

Antwort

Es gibt zwei Hauptgründe, warum das Hinzufügen der neuen Operatoren zu diesen Klassen problematisch wäre

• Derzeit definiert keine von beiden eine copy-Methode, die für | erforderlich wäre, um eine neue Instanz zu erstellen.
• Das Hinzufügen von |= zu MutableMapping (oder einer copy-Methode zu Mapping) würde Kompatibilitätsprobleme für virtuelle Unterklassen verursachen.

Fehler auslösen

Es ist nicht klar, ob dieses Verhalten viele Anwendungsfälle hat oder oft nützlich sein wird, aber es wird wahrscheinlich ärgerlich sein, da jede Verwendung des Dict-Union-Operators mit einer try/except-Klausel abgesichert werden müsste.

Werte addieren (wie Counter mit +)

Zu spezialisiert, um als Standardverhalten verwendet zu werden.

Der linke Wert (zuerst gesehen) gewinnt

Es ist nicht klar, ob dieses Verhalten viele Anwendungsfälle hat. Tatsächlich kann man einfach die Reihenfolge der Argumente umkehren

d2 | d1  # d1 merged with d2, keeping existing values in d1

Werte in einer Liste verketten

Dies ist wahrscheinlich zu spezialisiert, um das Standardverhalten zu sein. Es ist nicht klar, was zu tun ist, wenn die Werte bereits Listen sind.

{'a': [1, 2]} | {'a': [3, 4]}

Sollte dies ergeben {'a': [1, 2, 3, 4]} oder {'a': [[1, 2], [3, 4]]}?

Additionsoperator verwenden

Diese PEP begann ursprünglich als Vorschlag für die Dict-Addition unter Verwendung der Operatoren + und +=. Diese Wahl erwies sich als äußerst kontrovers, da viele Leute ernsthafte Einwände gegen die Wahl des Operators hatten. Details finden Sie unter früheren Versionen der PEP und den Diskussionen in der Mailingliste unter Diskussionen.

Links-Shift-Operator verwenden

Der Operator << erhielt auf Python-Ideas nicht viel Unterstützung, aber auch keine größeren Einwände. Vielleicht der stärkste Einwand war Chris Angelicos Kommentar

Der „Niedlichkeitswert“ des Missbrauchs des Operators zur Anzeige von Informationsfluss wurde kurz nachdem C++ es getan hatte, alt.

Neuen Links-Pfeil-Operator verwenden

Ein weiterer Vorschlag war, einen neuen Operator <- zu erstellen. Leider wäre dies mehrdeutig, d <- e könnte d zusammenführen e oder d weniger-als minus e bedeuten.

Eine Methode verwenden

Eine Methode dict.merged() würde die Notwendigkeit eines Operators ganz vermeiden. Eine Feinheit ist, dass sie wahrscheinlich leicht unterschiedliche Implementierungen benötigen würde, wenn sie als ungebundene Methode und als gebundene Methode aufgerufen wird.

Als ungebundene Methode könnte das Verhalten ähnlich sein wie

def merged(cls, *mappings, **kw):
    new = cls()  # Will this work for defaultdict?
    for m in mappings:
        new.update(m)
    new.update(kw)
    return new

Als gebundene Methode könnte das Verhalten ähnlich sein wie

def merged(self, *mappings, **kw):
    new = self.copy()
    for m in mappings:
        new.update(m)
    new.update(kw)
    return new

Eine Funktion verwenden

Anstatt einer Methode, verwenden Sie eine neue eingebaute Funktion merged(). Eine mögliche Implementierung könnte etwa so aussehen

def merged(*mappings, **kw):
    if mappings and isinstance(mappings[0], dict):
        # If the first argument is a dict, use its type.
        new = mappings[0].copy()
        mappings = mappings[1:]
    else:
        # No positional arguments, or the first argument is a
        # sequence of (key, value) pairs.
        new = dict()
    for m in mappings:
        new.update(m)
    new.update(kw)
    return new

Eine Alternative könnte sein, auf beliebige Schlüsselwörter zu verzichten und einen einzelnen Schlüsselwortparameter zu verwenden, der das Verhalten bei Kollisionen angibt.

def merged(*mappings, on_collision=lambda k, v1, v2: v2):
    # implementation left as an exercise to the reader