Ablehnungsbescheid

Die Gründe für die Ablehnung durch den Steering Council 2024 umfassen:

• Wir fanden keine Beweise für einen starken Konsens, dass diese Funktion in der Standardbibliothek benötigt wurde, obwohl einige Befürworter sie zur Reduzierung ihrer Abhängigkeit von Drittanbieterpaketen befürworteten. Für diejenigen, die eine solche Funktionalität benötigen, halten wir bestehende Drittanbieterbibliotheken wie attrs und Pydantic (auf die in PEP verwiesen wird) für akzeptable Alternativen.
• Diese Funktion scheint uns wie eine Ansammlung von dem, was als mehr Ballast in der Standardbibliothek betrachtet werden könnte, und führt uns immer weiter weg von den „einfachen“ Anwendungsfällen, für die Dataklassen ideal sind.
• Das Lesen des Abschnitts „How to Teach This“ der PEP lässt uns zweifeln, dass die Fallstricke und Tücken erheblich sind, wobei erhöhte Verwirrung und Komplexität die potenziellen Vorteile überwiegen.
• Die PEP scheint sich mehr auf die Unterstützung von Typüberprüfern als von Personen zu konzentrieren, die die Bibliothek verwenden.

Zusammenfassung

PEP 557 fügte dataclasses zur Python-Standardbibliothek hinzu. PEP 681 fügte dataclass_transform() hinzu, um Typüberprüfern das Verständnis mehrerer gängiger dataklassenähnlicher Bibliotheken zu erleichtern, wie z. B. attrs, Pydantic und Object Relational Mapper (ORM)-Pakete wie SQLAlchemy und Django.

Eine häufige Funktion, die andere Bibliotheken gegenüber der Standardimplementierung bieten, ist die Möglichkeit für die Bibliothek, an das Objekt übergebene Argumente bei der Initialisierung in die für jedes Feld erwarteten Typen mithilfe einer vom Benutzer bereitgestellten Konvertierungsfunktion zu konvertieren.

Daher fügt diese PEP einen Parameter converter zur Funktion dataclasses.field() hinzu (zusammen mit den erforderlichen Änderungen an dataclasses.Field und dataclass_transform()), um die Funktion anzugeben, die zur Konvertierung des Eingabewerts für jedes Feld in die zu speichernde Darstellung in der Dataklasse verwendet wird.

Motivation

Es gibt keine bestehende, standardmäßige Möglichkeit für dataclasses oder dataklassenähnliche Drittanbieterbibliotheken, Argumentkonvertierung auf eine typprüfbare Weise zu unterstützen. Um diese Einschränkung zu umgehen, sind Bibliotheksautoren/Benutzer gezwungen, Folgendes zu wählen:

• Opt-in für ein benutzerdefiniertes Mypy-Plugin. Diese Plugins helfen Mypy, die Konvertierungssemantik zu verstehen, andere Werkzeuge jedoch nicht.
• Verantwortung für die Konvertierung auf den Aufrufer des Dataklassenkonstruktors verlagern. Dies kann die Erstellung bestimmter Dataklassen unnötig wortreich und repetitiv machen.
• Bereitstellung einer benutzerdefinierten __init__-Methode, die „breitere“ Parametertypen deklariert und sie beim Zuweisen des entsprechenden Attributs konvertiert. Dies dupliziert nicht nur die Typ-Annotationen zwischen dem Konverter und __init__, sondern schließt den Benutzer auch von vielen Funktionen aus, die dataclasses bietet.
• Bereitstellung einer benutzerdefinierten __init__-Methode, jedoch ohne aussagekräftige Typ-Annotationen für die Parametertypen, die eine Konvertierung erfordern.

Keine dieser Optionen ist ideal.

Begründung

Das Hinzufügen von Argumentkonvertierungssemantiken ist nützlich und vorteilhaft genug, dass die meisten dataklassenähnlichen Bibliotheken Unterstützung dafür bieten. Das Hinzufügen dieser Funktion zur Standardbibliothek bedeutet, dass mehr Benutzer diese Vorteile nutzen können, ohne dass zusätzliche Bibliotheken erforderlich sind. Darüber hinaus können Drittanbieterbibliotheken Typüberprüfer auf ihre eigenen Konvertierungssemantiken hinweisen, indem sie zusätzliche Unterstützung in dataclass_transform() hinzufügen, was bedeutet, dass auch Benutzer dieser Bibliotheken davon profitieren.

Spezifikation

def str_or_none(x: Any) -> str | None:
  return str(x) if x is not None else None

@dataclasses.dataclass
class InventoryItem:
    # `converter` as a type (including a GenericAlias).
    id: int = dataclasses.field(converter=int)
    skus: tuple[int, ...] = dataclasses.field(converter=tuple[int, ...])
    # `converter` as a callable.
    vendor: str | None = dataclasses.field(converter=str_or_none))
    names: tuple[str, ...] = dataclasses.field(
      converter=lambda names: tuple(map(str.lower, names))
    )  # Note that lambdas are supported, but discouraged as they are untyped.

    # The default value is also converted; therefore the following is not a
    # type error.
    stock_image_path: pathlib.PurePosixPath = dataclasses.field(
      converter=pathlib.PurePosixPath, default="assets/unknown.png"
    )

    # Default value conversion extends to `default_factory`;
    # therefore the following is also not a type error.
    shelves: tuple = dataclasses.field(
      converter=tuple, default_factory=list
    )

item1 = InventoryItem(
  "1",
  [234, 765],
  None,
  ["PYTHON PLUSHIE", "FLUFFY SNAKE"]
)
# item1's repr would be (with added newlines for readability):
#   InventoryItem(
#     id=1,
#     skus=(234, 765),
#     vendor=None,
#     names=('PYTHON PLUSHIE', 'FLUFFY SNAKE'),
#     stock_image_path=PurePosixPath('assets/unknown.png'),
#     shelves=()
#   )

# Attribute assignment also participates in conversion.
item1.skus = [555]
# item1's skus attribute is now (555,).

Abwärtskompatibilität

Diese Änderungen führen keine Kompatibilitätsprobleme ein, da sie nur opt-in neue Funktionen einführen.

Sicherheitsimplikationen

Es gibt keine direkten Sicherheitsbedenken bei diesen Änderungen.

Wie man das lehrt

Dokumentation und Beispiele, die den neuen Parameter und das Verhalten erklären, werden den relevanten Abschnitten der Dokumentationsseite (hauptsächlich bei dataclasses) hinzugefügt und vom Dokument *What’s New* verlinkt.

Die hinzugefügte Dokumentation/Beispiele decken auch die „häufigen Fallstricke“ ab, auf die Benutzer von Konvertern wahrscheinlich stoßen werden. Solche Fallstricke umfassen:

• Notwendigkeit, None/Sentinel-Werte zu verarbeiten.
• Notwendigkeit, Werte zu verarbeiten, die bereits vom richtigen Typ sind.
• Vermeidung von Lambdas für Konverter, da der Typ des synthetisierten __init__-Parameters Any wird.
• Vergessen, Werte in den Bodies von benutzerdefinierten __init__-Methoden in eingefrorenen Dataklassen zu konvertieren.
• Vergessen, Werte in den Bodies von benutzerdefinierten __setattr__-Methoden in nicht eingefrorenen Dataklassen zu konvertieren.

Zusätzlich sollten potenziell verwirrende Pattern-Matching-Semantiken abgedeckt werden.

@dataclass
class Point:
    x: int = field(converter=int)
    y: int

match Point(x="0", y=0):
    case Point(x="0", y=0):  # Won't be matched
        ...
    case Point():  # Will be matched
        ...
    case _:
        ...

Es ist jedoch anzumerken, dass dieses Verhalten für jeden Typ gilt, der im Initialisierer eine Konvertierung durchführt, und Typüberprüfer sollten in der Lage sein, diesen Fallstrick zu erkennen.

match int("0"):
  case int("0"):  # Won't be matched
      ...
  case _:  # Will be matched
      ...

Referenzimplementierung

Die attrs-Bibliothek enthält bereits einen converter-Parameter mit denselben Konvertersemantiken (Konvertierung im Initialisierer und bei Attributzuweisungen), wenn der Dekorator @define verwendet wird.

CPython-Unterstützung wird in einem Branch im Fork des Autors implementiert.

Abgelehnte Ideen

Urheberrecht

Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.