Fast drei Jahre nach der letzten Hauptversion steht jetzt Version 3.0 von pandas, der Bibliothek zur Datenanalyse mit Python, am Start. Zu den wichtigsten Änderungen gehören der dedizierte String-Data-Typ str, eine verbesserte Copy-on-Write-Methode sowie eine neue Standardauflösung für datums- und zeitähnliche Daten. Letztere verwendet standardmäßig Mikrosekunden statt Nanosekunden, um Grenzwertfehler für Datumsangaben mit einem Jahr vor 1678 oder nach 2262 zu vermeiden.

Effizientere Datenanalyse

Bei installierter PyArrow-Bibliothek interpretiert pandas 3.0 String-Spalten automatisch als Datentyp str statt als NumPy-object. Das soll für Leistungssteigerung und effizientere Zuweisung von Python-Objekten sorgen. Wie der neue Code aussehen kann, zeigt folgendes Beispiel:

# Old behavior (pandas < 3.0)
>>> ser = pd.Series(["a", "b"])
>>> ser
0 a
1 b
dtype: object # <-- numpy object dtype

# New behavior (pandas 3.0)
>>> ser = pd.Series(["a", "b"])
>>> ser.dtype
>>> ser
0 a
1 b
dtype: str # <-- new string dtype

Mit pandas 3.0 ist Copy-on-Write (CoW) nun die Standard-Speicherverwaltungstechnik. Damit verhält sich jedes Index-Ergebnis wie eine Kopie, sodass Änderungen am Ergebnis den ursprünglichen DataFrame nicht beeinflussen.

Da verkettete Zuweisungen nicht mehr funktionieren, entfällt SettingWithCopyWarning. Damit können die copy()-Aufrufe zum Unterdrücken dieser Warnung entfallen, was ebenfalls eine Verbesserung der Performance bedeutet.

# Old behavior (pandas < 3.0) - chained assignment
df["foo"][df["bar"] > 5] = # This might modify df (unpredictable)

# New behavior (pandas 3.0) - must do the modification in one step (e.g. with .loc)
df.loc[df["bar"] > 5, "foo"] = 100

Schrittweises Upgrade empfohlen

Mit dem neuen Release hat das Pandas-Team einige veraltete Funktionen entfernt. Deshalb empfiehlt es, zunächst ein Upgrade auf pandas 2.3 durchzuführen, um sicherzustellen, dass der Code ohne Fehlermeldungen läuft. Erst anschließend sollte man den Wechsel auf Version 3.0 angehen.

Installieren lässt sich pandas 3.0 über PyPI mit python -m pip install --upgrade pandas==3.0.* oder über conda-forge mit conda install -c conda-forge pandas=3.0.

In den Release Notes von pandas 3.0.0 lassen sich sämtliche Änderungen im Detail nachlesen. Weil sie ein Code-Update erforderlich machen können, stellen die Entwicklerinnen und Entwickler Migrationsanleitungen zur Verfügung, unter anderem für den neuen String-Data-Typ und die Copy-on-Write-Methode.

(who)

Bei Bedarf entscheiden zentrale Programmierer von Linux zukünftig bei einem „Konklave“, wer die Entwicklung des Kernels fortan leitet. Zu so einer Versammlung soll es allerdings nur kommen, falls designierte Nachfolger den Posten nicht übernehmen können oder wollen.

Dieser bislang ungeklärte Fall ist ab jetzt über einen Text in einer Datei namens „conclave“ geregelt, den Linus Torvalds Samstagnacht in die Dokumentation seines Linux genannten Kernels eingepflegt hat. Der Text betont, dass die Entwicklung zwar einerseits verteilt erfolgt, schlussendlich aber durch ein einzelnes Paar Hände geht. Das sind seit Anbeginn die von Linus Torvalds, wenn man von einer Schaffenspause bei Linux 4.19 absieht.

Schaffenspause zeigt Arbeitsfähigkeit

Diese hat auch gezeigt, dass andere Entwickler Zugriff auf den Hauptentwicklungszweig des Kernels haben und die Entwicklungsleitung im Fall der Fälle schnell übernehmen können. Sollten diese Personen das aber nicht können oder wollen, obliegt es fortan dem Organisator des letzten Kernel Maintainer Summit, ein Meeting einzuberufen, um über das weitere Vorgehen zu entscheiden. Dazu lädt er mindestens die Teilnehmer des letzten Summits und die Mitglieder des Technical Advisory Board (TAB) der Linux Foundation ein; alle von ihnen können aber weitere ins Boot holen.

Triebkraft hinter dem Text mit dem neuen Prozedere war Dan Williams, der seit Jahren zu den zentralen Linux-Entwicklern zählt und auch Mitglied des TAB ist. Er hatte die Nachfolgeregelung im Dezember beim letzten Maintainer Summit angesprochen und den Text zwischenzeitlich ausgearbeitet.

Den ratifizierte Torvalds keine 24 Stunden nach der Veröffentlichung, indem er ihn in die Quellen integrierte – womit er letztlich die sonst bei Kernel-Änderung übliche öffentliche Diskussionsphase nach kurzer Zeit abwürgte.

Abwarten

Letztlich bleibt aber ohnehin abzuwarten, ob oder wann dieses Prozedere je angewendet werden wird: Das Ganze greift schließlich nur, wenn keiner von denen mit den nötigen Zugriffsrechten den Job übernehmen kann oder will. Einer von ihnen ist Greg Kroah-Hartman, der Torvalds bei der Entwicklung von 4.19 vertreten hat. Er gilt gemeinhin auch als designierter Nachfolger, wie wir im Herbst bereits näher erläutert haben: Missing Link: Wie es bei Linux ohne Linus Torvalds weiterginge

(dmk)

Softwarearchitektur hat seit Längerem das Problem, dass sie innerhalb von Systemgrenzen stattfindet, in denen jeweils spezifische Anforderungen dominieren: Enterprise-Systeme verlangen beispielsweise Flexibilität, Skalierbarkeit und schnelle Evolution. Embedded-Systeme hingegen benötigen direkten Hardwarezugriff, Echtzeitperformance und effiziente Ressourcen. Traditionelle Architekturmuster zwingen Architektinnen und Architekten oft, zwischen diesen Welten zu wählen oder separate Ansätze für unterschiedliche Systemtypen zu pflegen.

Das neue Muster Capability-centric Architecture (CCA) löst diese Spannung auf. Es erweitert und synthetisiert Konzepte aus Domain-driven Design, Hexagonal Architecture und Clean Architecture. Dabei führt es neue Mechanismen ein, die es gleichermaßen auf einen Mikrocontroller anwendbar machen, der Sensordaten liest, wie auf eine Cloud-native Enterpriseplattform, die Milliarden von Transaktionen verarbeitet.

Diese Artikelserie stellt das neue Muster in vier Artikeln vor. Hier im ersten Teil geht es um die Grundlagen der Methode. Anschließend folgen drei Beispiele, für ein Embedded-System, für eine Enterprise-Anwendung und für eine Architektur mit KI-Komponente.

Fundamentale Probleme mit existierenden Ansätzen

Das Muster entstand aus unserer Analyse, warum existierende Architekturen versagen, wenn Systeme evolvieren müssen, neue Technologien wie KI und Containerisierung integrieren sollen oder das Embedded-bis-Enterprise-Spektrum überspannen. Anstatt diese Anforderungen als separate Probleme zu behandeln, bietet CCA ein vereinheitlichtes konzeptionelles Framework mit Mechanismen zur Verwaltung von Komplexität, Abhängigkeiten und Änderungen.

Ein Beispiel für einen unzureichenden Ansatz ist es, eine typische geschichtete Architektur auf ein industrielles Steuerungssystem anzuwenden. Die Präsentationsschicht zeigt Sensorwerte an, die Schicht der Businesslogik verarbeitet Steuerungsalgorithmen, die Datenzugriffsschicht verwaltet Persistenz, und irgendwo erfolgt Hardwarezugriff zum Lesen von Sensoren und zur Steuerung der Aktoren.

Das unmittelbare Problem liegt auf der Hand: Wo passt die Hardwareschicht hin? Unterhalb der Datenzugriffsschicht erzeugt sie eine ungeschickte Abhängigkeitsstruktur. Als separates Anliegen verletzt sie das Schichtenprinzip. Kritischer noch: Die starre Schichtung macht es nahezu unmöglich, kritische Pfade zu optimieren. Wenn ein Sensor-Interrupt auftritt, muss das Signal mehrere Schichten durchlaufen, bevor es den Steuerungsalgorithmus erreicht, was eine inakzeptable Latenz bedeutet.

Hexagonal Architecture versucht, dies durch Ports und Adapter zu lösen. Die Kern-Domänenlogik sitzt im Zentrum, und Adapter verbinden zu externen Systemen durch definierte Ports. Dies funktioniert gut für Enterprise-Systeme mit Datenbank- und API-Adaptern. Für Embedded-Systeme jedoch verschleiert die Behandlung eines Hardware-Timers als weiteren Adapter den fundamentalen Unterschied zwischen einem austauschbaren, externen Service und einer Hardwarekomponente, die die Echtzeitfähigkeit des Systems definiert.

Ein typischer hexagonaler Ansatz für Embedded-Systeme sieht folgendermaßen aus:

// Port-Definition
public interface SensorPort {
    SensorReading read();
}

// Domain-Logik
public class TemperatureController {
    private final SensorPort sensor;
    
    public TemperatureController(SensorPort sensor) {
        this.sensor = sensor;
    }
    
    public void regulate() {
        SensorReading reading = sensor.read();
        // Steuerungslogik hier
    }
}

// Hardware-Adapter
public class HardwareSensorAdapter implements SensorPort {
    private static final int SENSOR_REGISTER = 0x40001000;
    
    public SensorReading read() {
        // Direkter Speicherzugriff
        int rawValue = readRegister(SENSOR_REGISTER);
        return new SensorReading(convertToTemperature(rawValue));
    }
    
    private native int readRegister(int address);
}

Der Code sieht sauber aus, verbirgt aber kritische Probleme. Die Abstraktion verhindert, dass der Controller auf Sensor-Metadaten zugreift, die in benachbarten Hardwareregistern verfügbar sind. Sie erzwingt alle Sensorzugriffe durch einen Methodenaufruf und verhindert den direkten Speicherzugriff per DMA oder Interrupt-gesteuertes Lesen. Sie macht Tests schwieriger, weil Entwickler Timing-Verhalten nicht einfach injizieren können. Am kritischsten: Sie behandelt Hardware als nur eine weitere austauschbare Komponente, obwohl die Hardwarefähigkeiten fundamental die Leistung des Systems prägen.

Clean Architecture steht vor ähnlichen Problemen. Ihre konzentrischen Kreise mit nach innen zeigenden Abhängigkeiten funktionieren wunderbar für Geschäftsanwendungen. Die Entities-Schicht enthält Geschäftsregeln, die Use-Cases-Schicht anwendungsspezifische Regeln, und äußere Schichten behandeln UI und Infrastruktur. Aber Embedded-Systeme passen nicht in dieses Modell. Hardware ist keine Infrastruktur, die sich abstrahieren lässt. Sie ist das Fundament, auf dem Fähigkeiten aufgebaut sind.

Enterprise-Systeme stehen vor unterschiedlichen, aber gleichermaßen herausfordernden Problemen. Während die Systeme wachsen, vermehren sich Bounded Contexts, und die Abhängigkeiten zwischen ihnen verheddern sich. Teams versuchen Schichtung oder hexagonale Grenzen durchzusetzen, was aber in praktischen Zwängen resultiert und Hintertüren sowie Abkürzungen schafft. Ein Kundenservice benötigt Daten vom Inventarservice, der Preise vom Katalogservice braucht, der wiederum Kundensegmente vom Kundenservice benötigt. Die zirkuläre Abhängigkeit ist offensichtlich, das Geschäftsbedürfnis aber real.

Moderne Technologien verschärfen diese Probleme. KI-Modelle sind keine einfachen Komponenten, die in eine Schicht oder einen Adapter passen. Sie haben eigene Infrastrukturbedürfnisse, Training-Pipelines, Anforderungen an die Versionierung und Inferenz-Charakteristiken. Big-Data-Verarbeitung passt nicht zu traditionellen Request-Response-Mustern. Infrastructure-as-Code verwischt die Grenze zwischen Anwendungs- und Deployment-Architektur. Kubernetes und Containerisierung ändern, wie Architekten über Deployment-Einheiten und Skalierungsgrenzen denken.