Obacht! Wenn das PythonPart ein neues Element erstellt, tut es das immer, auch wenn es nur "modifiziert" wird. D.h. jeder Doppelklick links zum Modifizieren erzeugt immer wieder neue Elemente!

Das kann nicht so gewollt sein, oder?

Besser wäre es, wenn das PythonPart nur der "Modifikator" der Elemente ist, und selbst nur eine Dummy-Darstellung produziert.
Der Pythonpart-Modifikator würde aber seine "Kinder" kennen (ob über Verknüpfung (OwendObjects) oder über UUID-Adresse), und diese auch modifizieren können.

Ein schönes, einfaches Beispiel wäre ein "Verteilen"-Modifikator. Dieser hätte eine 2D-Linie als Darstellung, und würde die zugeordneten Element (z.B. Stützen) in gleichem Abstand auf dieser Linie platzieren. Bei ersten Mal durch einfaches Kopieren der Ausgangsstütze, beim Modifizieren durch Verschieben der dann schon verhandenen Stützen!
Man könnte beim Modifikator dann Linielänge/ -lage und Anzahl ändern, und die Stützen würden entspr. neu ausgerichtet! Und das auch, wenn der Anwender z.B. die 3. Stütze schon in eine runde Stütze gewandelt hat und bei der 4. Stütze die Höhe geändert wurde. Noch besser kann man sich das sicher mit verschiedenen Fenster-Öffnungen vorstellen, die anhand eines bestimmtes "Rhythmus" in der Wand angeordnet werden sollen.

Wenn man diesen Workflow irgendwann mal mit PythonParts abbilden kann, wäre das eine sehr hilfreiche Ergänzung für die Allplan-Funktionen! Die Modifikationen müssen dabei nicht auf die Position beschränkt bleiben.

Leider kann man mit der NOI nicht alle Architektur-Elemente "updaten", sonst hätte ich dafür schon längst ein Plugin programmiert!
Mal sehen, ob das mit PythonParts irgendwann möglich wird...