Klassen

Heutzutage gibt es drei Hauptmethoden, um schreibgeschützte Attribute zu erreichen, die von Typ-Prüfern unterstützt werden:

• Annotation des Attributs mit typing.Final

  class Foo:
      number: Final[int]
  
      def __init__(self, number: int) -> None:
          self.number = number
  
  
  class Bar:
      def __init__(self, number: int) -> None:
          self.number: Final = number
  

  • Unterstützt von dataclasses (und Typ-Prüfern seit typing#1669).
  • Die Überschreibung von number ist nicht möglich – die Spezifikation von Final besagt, dass der Name in Unterklassen nicht überschrieben werden kann.
• Schreibgeschützter Proxy über @property

  class Foo:
      _number: int
  
      def __init__(self, number: int) -> None:
          self._number = number
  
      @property
      def number(self) -> int:
          return self._number
  

  • Die Überschreibung von number ist möglich. *Typ-Prüfer sind sich über die genauen Regeln uneinig.* [1]
  • Schreibgeschützt zur Laufzeit. [2]
  • Erfordert zusätzlichen Boilerplate-Code.
  • Unterstützt von dataclasses, aber schlecht zusammensetzbar – das synthetisierte __init__ und __repr__ verwenden _number als Parameter-/Attributnamen.
• Verwendung eines "Einfrier"-Mechanismus, wie dataclasses.dataclass() oder typing.NamedTuple

  @dataclass(frozen=True)
  class Foo:
      number: int  # implicitly read-only
  
  
  class Bar(NamedTuple):
      number: int  # implicitly read-only
  

  • Die Überschreibung von number ist im @dataclass-Fall möglich.
  • Schreibgeschützt zur Laufzeit. [2]
  • Keine Kontrolle pro Attribut – diese Mechanismen gelten für die gesamte Klasse.
  • Eingefrorene Dataclasses verursachen einen gewissen Laufzeit-Overhead.
  • NamedTuple ist immer noch ein tuple. Die meisten Klassen müssen keine Indizierung, Iteration oder Verkettung erben.

Protokolle

Angenommen, ein Mitglied name: T eines Protocol, das zwei Anforderungen definiert:

1. hattr(obj, "name")
2. istinstance(obj.name, T)

Diese Anforderungen sind zur Laufzeit durch alle folgenden Elemente erfüllbar:

• ein Objekt mit einem Attribut name: T,
• eine Klasse mit einer Klassenvariable name: ClassVar[T],
• eine Instanz der obigen Klasse,
• ein Objekt mit einem @property def name(self) -> T,
• ein Objekt mit einem benutzerdefinierten Deskriptor, wie functools.cached_property().

Die aktuelle Typing-Spezifikation erlaubt die Erstellung solcher Protokollmitglieder unter Verwendung von (abstrakten) Eigenschaften

class HasName(Protocol):
    @property
    def name(self) -> T: ...

Diese Syntax hat mehrere Nachteile:

• Sie ist etwas umständlich.
• Es ist nicht offensichtlich, dass die hier vermittelte Qualität der schreibgeschützte Charakter einer Eigenschaft ist.
• Sie ist nicht mit Typ-Qualifizierern komponierbar.
• Nicht alle Typ-Prüfer stimmen überein [3], dass alle der oben genannten fünf Objekte dieser strukturellen Art zuweisbar sind.

Initialisierung

Die Zuweisung zu einem schreibgeschützten Attribut kann nur in der Klasse erfolgen, die das Attribut deklariert. Es gibt keine Einschränkung, wie oft das Attribut zugewiesen werden kann. Je nach Art des Attributs kann es an verschiedenen Stellen zugewiesen werden:

from collections import abc
from typing import ReadOnly


class Band:
    name: str
    songs: ReadOnly[list[str]]

    def __init__(self, name: str, songs: abc.Iterable[str] | None = None) -> None:
        self.name = name
        self.songs = []

        if songs is not None:
            self.songs = list(songs)  # multiple assignments are fine

    def clear(self) -> None:
        # error: assignment to read-only "songs" outside initialization
        self.songs = []


band = Band(name="Bôa", songs=["Duvet"])
band.name = "Python"           # ok: "name" is not read-only
band.songs = []                # error: "songs" is read-only
band.songs.append("Twilight")  # ok: list is mutable


class SubBand(Band):
    def __init__(self) -> None:
        self.songs = []  # error: cannot assign to a read-only attribute of a base class

# a simplified immutable Fraction class
class Fraction:
    numerator: ReadOnly[int]
    denominator: ReadOnly[int]

    def __new__(
        cls,
        numerator: str | int | float | Decimal | Rational = 0,
        denominator: int | Rational | None = None
    ) -> Self:
        self = super().__new__(cls)

        if denominator is None:
            if type(numerator) is int:
                self.numerator = numerator
                self.denominator = 1
                return self

            elif isinstance(numerator, Rational): ...

        else: ...

    @classmethod
    def from_float(cls, f: float, /) -> Self:
        self = super().__new__(cls)
        self.numerator, self.denominator = f.as_integer_ratio()
        return self

class URI:
    protocol: ReadOnly[ClassVar[str]] = ""

    def __init_subclass__(cls, protocol: str = "") -> None:
        cls.protocol = protocol

class File(URI, protocol="file"): ...

class Patient:
    number: ReadOnly[int] = 0

    def __init__(self, number: int | None = None) -> None:
        if number is not None:
            self.number = number

class Patient:
    id: ReadOnly[int]    # error: "id" is not initialized on all code paths
    name: ReadOnly[str]  # error: "name" is never initialized

    def __init__(self) -> None:
        if random.random() > 0.5:
            self.id = 123


class HasName(Protocol):
    name: ReadOnly[str]  # ok

Subtyping

Die Unmöglichkeit, schreibgeschützte Attribute neu zuzuweisen, macht sie kovariant. Dies hat einige Subtyping-Implikationen. Übernommen aus PEP 705

• Schreibgeschützte Attribute können als beschreibbare Attribute, Deskriptoren oder Klassenvariablen neu deklariert werden.

  @dataclass
  class HasTitle:
      title: ReadOnly[str]
  
  
  @dataclass
  class Game(HasTitle):
      title: str
      year: int
  
  
  game = Game(title="DOOM", year=1993)
  game.year = 1994
  game.title = "DOOM II"  # ok: attribute is not read-only
  
  
  class TitleProxy(HasTitle):
      @functools.cached_property
      def title(self) -> str: ...
  
  
  class SharedTitle(HasTitle):
      title: ClassVar[str] = "Still Grey"
  

• Wenn ein schreibgeschütztes Attribut nicht neu deklariert wird, bleibt es schreibgeschützt.

  class Game(HasTitle):
      year: int
  
      def __init__(self, title: str, year: int) -> None:
          super().__init__(title)
          self.title = title  # error: cannot assign to a read-only attribute of base class
          self.year = year
  
  
  game = Game(title="Robot Wants Kitty", year=2010)
  game.title = "Robot Wants Puppy"  # error: "title" is read-only
  

• Untertypen können den Typ von schreibgeschützten Attributen verengen.

  class GameCollection(Protocol):
      games: ReadOnly[abc.Collection[Game]]
  
  
  @dataclass
  class GameSeries(GameCollection):
      name: str
      games: ReadOnly[list[Game]]  # ok: list[Game] is assignable to Collection[Game]
  

• Nominale Unterklassen von Protokollen und ABCs sollten schreibgeschützte Attribute neu deklarieren, um sie zu implementieren, es sei denn, die Basisklasse initialisiert sie auf irgendeine Weise.

  class MyBase(abc.ABC):
      foo: ReadOnly[int]
      bar: ReadOnly[str] = "abc"
      baz: ReadOnly[float]
  
      def __init__(self, baz: float) -> None:
          self.baz = baz
  
      @abstractmethod
      def pprint(self) -> None: ...
  
  
  @final
  class MySubclass(MyBase):
      # error: MySubclass does not override "foo"
  
      def pprint(self) -> None:
          print(self.foo, self.bar, self.baz)
  

• In einer Protokollattribut-Deklaration zeigt name: ReadOnly[T] an, dass ein struktureller Subtyp den Zugriff auf .name unterstützen muss und der zurückgegebene Wert T zuweisbar ist.

  class HasName(Protocol):
      name: ReadOnly[str]
  
  
  class NamedAttr:
      name: str
  
  class NamedProp:
      @property
      def name(self) -> str: ...
  
  class NamedClassVar:
      name: ClassVar[str]
  
  class NamedDescriptor:
      @cached_property
      def name(self) -> str: ...
  
  # all of the following are ok
  has_name: HasName
  has_name = NamedAttr()
  has_name = NamedProp()
  has_name = NamedClassVar
  has_name = NamedClassVar()
  has_name = NamedDescriptor()
  

Interaktion mit anderen Typ-Qualifizierern

ReadOnly kann mit ClassVar und Annotated in beliebiger Verschachtelungsreihenfolge verwendet werden.

class Foo:
    foo: ClassVar[ReadOnly[str]] = "foo"
    bar: Annotated[ReadOnly[int], Gt(0)]

class Foo:
    foo: ReadOnly[ClassVar[str]] = "foo"
    bar: ReadOnly[Annotated[int, Gt(0)]]

Dies steht im Einklang mit der Interaktion von ReadOnly und typing.TypedDict, wie in PEP 705 definiert.

Ein Attribut kann nicht gleichzeitig als ReadOnly und Final annotiert werden, da die beiden Qualifizierer unterschiedliche Semantiken aufweisen und Final im Allgemeinen restriktiver ist. Final bleibt als Annotation von Attributen zulässig, die nur implizit schreibgeschützt sind. Es kann auch verwendet werden, um ein ReadOnly-Attribut einer Basisklasse neu zu deklarieren.

Klärung der Interaktion von @property und Protokollen

Der Abschnitt Protokolle erwähnt eine Inkonsistenz zwischen Typ-Prüfern bei der Interpretation von Eigenschaften in Protokollen. Das Problem könnte durch eine Änderung der Typing-Spezifikation behoben werden, die klärt, was die schreibgeschützte Qualität solcher Eigenschaften implementiert.

Dieser PEP macht ReadOnly zu einer besseren Alternative für die Definition schreibgeschützter Attribute in Protokollen und ersetzt die Verwendung von Eigenschaften zu diesem Zweck.

Zuweisung nur in __init__ und Klassenkörper

Eine frühere Version dieses PEP schlug vor, dass schreibgeschützte Attribute nur in __init__ und dem Klassenkörper zugewiesen werden könnten. Eine spätere Diskussion ergab, dass diese Einschränkung die Nutzbarkeit von ReadOnly in unveränderlichen Klassen, die typischerweise keine __init__ definieren, stark einschränken würde.

fractions.Fraction ist ein Beispiel für eine unveränderliche Klasse, in der die Initialisierung ihrer Attribute innerhalb von __new__ und Classmethods erfolgt. Im Gegensatz zu __init__ ist die Zuweisung in __new__ und Classmethods jedoch potenziell nicht korrekt, da die Instanz, auf der sie arbeiten, von einer beliebigen Stelle stammen kann, einschließlich einer bereits finalisierten Instanz.

Wir halten es für unerlässlich, dass dieses Typ-Checking-Merkmal für den wichtigsten Anwendungsfall von schreibgeschützten Attributen – unveränderliche Klassen – nützlich ist. Daher wurde der PEP dahingehend geändert, die Zuweisung in __new__ und Classmethods unter einer Reihe von Regeln zuzulassen, die im Abschnitt Initialisierung beschrieben sind.

Erweiterung der Initialisierung

Mechanismen wie dataclasses.__post_init__() oder die Initialisierungs-Hooks von attrs erweitern die Objekterstellung, indem sie eine Reihe spezieller Hooks bereitstellen, die während der Initialisierung aufgerufen werden.

Die aktuellen Initialisierungsregeln dieses PEP verbieten die Zuweisung zu schreibgeschützten Attributen in solchen Methoden. Es ist unklar, ob die Regeln zufriedenstellend gestaltet werden könnten, um diese Hooks von Drittanbietern einzubeziehen und gleichzeitig die mit der Schreibgeschütztheit dieser Attribute verbundenen Invarianten aufrechtzuerhalten.

Das Python-Typsystem hat eine lange und detaillierte Spezifikation bezüglich des Verhaltens von __new__ und __init__. Es ist eher unrealistisch, das gleiche Detaillierungsniveau von Hooks Dritter zu erwarten.

Eine mögliche Lösung bestünde darin, dass Typ-Prüfer diesbezüglich Konfigurationen bereitstellen und Endbenutzer manuell eine Reihe von Methoden angeben müssen, für die sie eine Initialisierung zulassen möchten. Dies könnte jedoch leicht dazu führen, dass Benutzer die oben genannten Invarianten fälschlicherweise oder absichtlich brechen. Es ist auch eine ziemlich große Anforderung für ein relativ nischenhaftes Merkmal.