Ein großes Python-Datensystem ändern, ohne die verzögerte Ausführung auszuhebeln

## Das gewünschte Verhalten bis zur zuständigen Schicht verfolgen Erstelle vor Änderungen an einem großen Python-Daten- oder Parallelverarbeitungssystem eine auf die Aufgabe zugeschnittene Übersicht, statt den gesamten Quelltextbestand wahllos zu lesen. Bestimme die beteiligten Schichten: 1. Öffentliche Sammlungen oder nutzergerichtete Schnittstellen. 2. Symbolische Ausdrücke oder hochstufige Graphen für Planung und Optimierung. 3. Konkretisierte, niedrigstufige Aufgaben und Abhängigkeitskanten. 4. Ablaufsteuerungen oder Ausführungssysteme. 5. Schichten für Konfiguration, Verteilung, Serialisierung und Hilfsfunktionen. Verfolge das angeforderte Verhalten vom öffentlichen Einstiegspunkt bis zur kleinsten zuständigen Implementierungsschicht. Lies vor der Bearbeitung angrenzende Tests und Konfigurationen. Navigiere entsprechend der Aufgabe: - Ablaufsteuerung: öffentliche Berechnungsschnittstellen, Graphhilfen, Aufgabendarstellungen und anschließend Anbindungen der Ablaufsteuerung. - Graphoptimierung: Protokolle hochstufiger Graphen, blockweise oder ausdrucksbasierte Schichten und anschließend die Konkretisierung. - Funktionen für Datenfelder oder tabellarische Datenstrukturen: Sammlungsschnittstelle, Umsetzung der Operation, Verteilung und anschließend gezielte Tests. - Konfigurationsänderungen: Laufzeitzugriffe, Vorgabekonfiguration, Schema und Dokumentation. - Unterstützung eines Ausführungssystems: dessen Schnittstelle, Registrierung des Einstiegspunkts, Verteilung und Kompatibilitätstests. Betrachte Modulnamen, Zeilenzahlen und Abhängigkeitsversionen in Hinweisen des Quelltextbestands als Orientierung, nicht als dauerhaft gültige Tatsachen. Bestätige den aktuellen Quelltext und die Manifeste vor Ort. Halte die Grenzen der Teilsysteme ausdrücklich sichtbar. Eine Änderung an einer öffentlichen Sammlung kann entsprechende Anpassungen an Metadaten, Graph, Ablaufsteuerung, Tests und Dokumentation erfordern; bearbeite jedoch keine unbeteiligten Schichten. ## Die Umgebungen des Repositorys nutzen und den kleinsten Testumfang wählen Verwende die vom Quelltextbestand angegebene Umgebungsverwaltung und die dort festgelegten Befehle. Gehe nicht davon aus, dass eine systemweit installierte Python-Version den unterstützten Abhängigkeitskombinationen entspricht. Vor der Umsetzung: 1. Prüfe das Projektmanifest und die verfügbaren Umgebungen. 2. Wähle die kleinste Umgebung, die die betroffene Funktion abbildet. 3. Finde die nächstgelegenen vorhandenen Tests, Testvorrichtungen, Markierungen und Prüfhilfen. 4. Halte wichtige optionale Abhängigkeiten, Funktionsschalter und Warnungsregeln fest. Bevorzuge die vom Quelltextbestand bereitgestellten Befehlsaufrufe für: - einen einzelnen fehlschlagenden Test; - die Testdatei des betroffenen Moduls; - Stil- und statische Prüfungen; - Dokumentationstests öffentlicher Beispiele; - Umgebungen mit Mindestabhängigkeiten oder optionalen Funktionen; - umfassendere Prüfungen entsprechend der automatischen Integration nur dann, wenn die Änderung sie rechtfertigt. Beachte strenges Testverhalten wie als Fehler behandelte Warnungen, strikt behandelte erwartete Fehlschläge, Zeitbegrenzungen und umgebungsspezifische Markierungen. Verwende gemeinsame Gleichheitsprüfungen für verzögerte Sammlungen, wenn diese Metadaten, Typen, Partitionen oder numerische Toleranzen berücksichtigen. Verwende bei optionalen Abhängigkeiten die vorgesehenen Hilfen zum Importieren und Überspringen statt kurzfristig eingefügter Bedingungen. Berücksichtige beim Einsatz neuer Schnittstellen die kleinste und die neueste unterstützte Version. Installiere keine Pakete, ändere keine Umgebungen und aktiviere keine netzabhängigen Tests, sofern die Aufgabe dies nicht erlaubt. Melde eine fehlende Abhängigkeit als Einschränkung der Umgebung, statt das System stillschweigend zu verändern. ## Verzögerte Ausführung wahren: beim Aufbau von Graphen kein `compute()` aufrufen Bewahre die zentrale Invariante verzögerter Graphsysteme: Quelltext zum Aufbau eines Graphen muss die Berechnung beschreiben, ohne sie auszuführen. Rufe beim Definieren von Sammlungsoperationen, Graphschichten oder symbolischen Ausdrücken niemals sofort konkretisierende Methoden wie `compute()` oder `persist()` auf. Die Konkretisierung gehört an eine ausdrückliche Nutzer- oder Ausführungsgrenze. Während des Graphaufbaus: - leite Ergebnisse nach Möglichkeit aus Metadaten ab; - halte Aufgabenabhängigkeiten ausdrücklich und deterministisch; - bewahre stabile Schlüssel und gleichbleibendes Tokenisierungsverhalten; - vermeide verborgene Ein- oder Ausgabe und die Auswahl einer Ablaufsteuerung; - trenne symbolische Optimierung weiterhin von der niedrigstufigen Ausführung. Befolge die Konventionen des Quelltextbestands: - ergänze neuen Quelltext um vollständige Typangaben; - halte Kompatibilitätsimporte und verzögerte Annotationen konsistent; - verwende geschützte, ausschließlich typbezogene Importe, um Zyklen zu vermeiden; - ordne Importe aus Standardbibliothek, Drittanbieterpaketen und lokalen Modulen vorhersehbar; - verwende für öffentliche Schnittstellen den dokumentierten Stil für Dokumentationszeichenfolgen und ausführbare Beispiele; - befolge die festgelegte Benennung für private Hilfsfunktionen, Tests und Verteilfunktionen. Aktualisiere beim Ergänzen eines Ausführungssystems, Ausdrucks, einer Schicht oder Konfigurationsoption jeden erforderlichen Registrierungspunkt und füge einen gezielten Test hinzu, der belegt, dass Verteilung oder Planung die neue Umsetzung erreicht. Funktionsschalter, die die Registrierung beim Import oder die Abfrageplanung beeinflussen, müssen vor dem ersten Import des betreffenden Moduls gesetzt werden. Prüfe aktiviertes und deaktiviertes Verhalten, wenn beide weiterhin unterstützt werden. Vermeide umfassende Umstrukturierungen, während du einen klar begrenzten Fehler behebst. Bewahre unbeteiligtes Verhalten und nimm nur die kleinste Änderung vor, die das neue Testergebnis erklärt. ## Tests schrittweise ausweiten und nie ohne Erlaubnis veröffentlichen Prüfe mit schrittweise wachsendem Umfang: 1. Stelle den bisherigen Fehler mit einem gezielten Test nach. 2. Führe die nächstgelegene Testdatei oder Testsammlung des Teilsystems aus. 3. Führe die von der Bearbeitung direkt betroffenen Stil-, Typ- oder Dokumentationsprüfungen aus. 4. Führe die relevanten Varianten mit optionalen Funktionen, Mindestabhängigkeiten oder Funktionsschaltern aus. 5. Verwende die vollständige Testsammlung nur, wenn die Änderung weitreichende Architekturgrenzen überschreitet. Prüfe häufige Fehlerursachen: - Importzyklen und Registrierungsreihenfolge; - nach dem ersten Import geänderte Funktionsschalter; - Metadaten, die nicht mit berechneten Ergebnissen übereinstimmen; - optionale Pakete, die in manchen Laufzeitumgebungen nicht verfügbar sind; - auseinanderlaufende Versionsbindungen von Abhängigkeiten in zusammengehörigen Paketen; - im Schema fehlende Konfigurationsvorgaben; - nicht mehr ausführbare Beispiele in Dokumentationstests; - Tests, die nur mit einer Ablaufsteuerung oder einem Ausführungssystem bestehen. Prüfe vor der Abschlussmeldung den Änderungssatz und nenne, welche Prüfungen tatsächlich ausgeführt wurden, welche bestanden und welche nicht ausgeführt wurden. Leite Erfolg nicht allein aus der Betrachtung des Quelltexts ab. Veröffentlichungsarbeit bildet eine eigene Berechtigungsgrenze. Erstelle niemals eine Veröffentlichung, veröffentliche keine Pakete, übertrage keine Versionsmarkierungen, lade keine Auslieferungsdateien hoch und verändere keine externen Veröffentlichungssysteme, sofern dies nicht ausdrücklich genehmigt wurde. Wenn die Vorbereitung einer Veröffentlichung genehmigt ist, prüfe Einträge im Änderungsprotokoll, Versionen und paketübergreifende Versionsbindungen, das Paketergebnis und die dokumentierte Reihenfolge des Quelltextbestands, bevor du einen externen Zustand änderst. Wenn du mit anderen Personen kommunizieren sollst, lege Belege und Möglichkeiten dar, ohne dich als Nutzer auszugeben oder dessen Entscheidungen zu erfinden.