Wie Embedded-Python und PIP?

[0KommaNix]

Danke himitsu!
Da lieferst du mir eine Menge Input . Den muss ich erstmal verarbeiten, bevor ich zu chaotisch nachfrage. Bisher habe ich Python nur für mich benutzt und das auch nur getrennt von Delphi-Programmen. Was du schreibst klingen sehr danach, dass ihr leitvolle Erfahrung sammeln musstet. Das macht mich schon Mal vorsichtiger.

Zwischenzeitlich habe ich gelernt, dass venv nicht unabhängig vom global installierten Python ist (ich war so blauäugige das zu glauben ). Nun habe ich gesehen, dass P4D nach einer pyvenv.cfg sucht und darin steht ein absoluter Verweis zum globalen Python.
Bei mein heutigen Versuchen musste ich feststellen, dass wenn ein Skript unter venv in ein Kommandozeilenfenster läuft, es nicht bedeutet, dass es auch von P4D-Demo1 Skript-Memo aus läuft. Bis zum produktiven Einsatz scheint es noch ein weiter Weg zu sein.

[himitsu]

Nja, wir hatten ursprünglich Python als "Embedded" mitgeliefert (nur nannte es damals noch niemand so).
Also als ZIP runtergeladen und die EXE (inkl. DLL und Co.) als Unterverzeichnis beim Programm.

Das aktuelle Script wurde als .py-Datei auf die Festplatte geschieben,
dann die Python.exe gestartet, die Datei als Parameter übergeben und dann via ShellExecute/CreateProzess die Ausgabe in eine Datei umgeleitet.
Später der Ausgabestream direkt im CreateProzess übergeben und die Ausgabe in ein unsichtbares TMemo, was dann weiterverwendet wurde und sich beim Dedbuggen anzeigen ließ.

Zuletzt dann Python4Delphi eingeführt, wo das Script als Stream/String im Programm bleibt und auch die Ausgabe in einem Stream/String landet.
Zusätzlich noch ein paar Variablen und Delphi-Funktionen reingegeben, welche sich im Python nutzen lassen.
Auch lässt sich hier intern schöner die Fehlerbehandlung machen. Also vorher ein SyntaxCheck und bei einem Fehler erweiterte Fehlerinfos von der DLL abrufen.

Dann ging es darum auch Fremdcode zu nutzen (bisher vorwiegend nur selbsterstellte PythonScripte)
und da sind wir dann zu PIP übergegangen, da es manuell schnell umständlich wird, mit all den Abhängigkeiten.

Als allerletztes dann noch die Ausgabe im Python auf Unicode umgestellt, denn rein ging es schon als Unicode, aber die Ausgabe sollte eigentlich UTF-8 sein (war aber ANSI).



Bei der EXE war es so, dass die Python-Instanz immer neu ist
und ein Script niemals Auswirkungen auf nachfolgende Scripte hat.

-> Wurde z.B. in einem Script vergessen eine Variable zu initialisieren,
dann was diese Variable in der EXE immer leer,
aber nun in der DLL hatte sie den Wert einer vorhergehenden Ausführung, was das Verhalten manchmal plötzlich veränderte.



Da wir damals es nicht geschafft hatten, die Instanz (Variablen und geladene Module) zurückzusetzen,
wird aktuell nach jeder Ausführung eines Scriptes die Instanz freigegeben und die Python-DLL entladen.
Beim nächsten Laden war somit alles wieder neu/leer.
Das lief bisher gut und auch flott.

Dann versuchte jemand PySide2 und shiboken2 nutzen zu wollen.
Ersteres lädt selbst DLLs und entlädt sich nicht mehr. (Entwickler für Scriptsprachen sind einfach nur faule Schlampen ... siehe meine Signaur)

Diese DLLs haben auch noch eine Referenz auf die python3.dll, welche wiederrum die python38.dll (welche wir geladen haben und nutzen) referenziert, womit sich alles gegenseitig im RAM festkrallt, nachdem wir unsere Referenz auf die python38.dll freigaben und dachten es wäre nun entladen.

Erstmal hatte hier Python4Delphi einen Bug, so dass es in der Finalisazion beim Entladen der einen DLL einen Exception gibt (das ist OK), aber nachfolgend anderes vergessen wird zu finalisieren und freizugeben. (try-finally vergessen)

Dennoch bleibt irgendwas im RAM (auch wenn manuell alle DLLs entladen werden), was dann beim nächsten Laden und der Initialisation zu einer Exception führt und es nicht mehr erlaubt weitere Scripte auszuführen (python4delphi bricht beim Laden und starten des Scripts ab).

Ja, ich kann manuell diese DLLs in der richigen Reihenfolge entladen (testweise für PySide2 gemacht),
aber da der Code universell sein muß, weil ich garnicht weiß, welche Komponenten/PythonModule zukünftig genuzt werden.
Hier hab ich mich nun mühevoll in Windows "gehackt", um an die LadeListen der DLLs zu kommen (inkl. Rehenfolge/Uhrzeit und dem Grund des Ladens, also manuell oder durch automatische Abhängigkeit)
Das wird nun genutzt die FremdDLLs zu finden und zu entladen.

Aber wie gesagt, irgendwo bleibt noch was zurück und knallt nachfolgend. Das hatte ich noch nicht gefunden, drum hängt das Projekt hier erstmal, da Anderes wichtiger.

[0KommaNix]

Zitat von himitsu:

Aber wie gesagt, irgendwo bleibt noch was zurück und knallt nachfolgend. Das hatte ich noch nicht gefunden, drum hängt das Projekt hier erstmal, da Anderes wichtiger.

Das kenn ich nur zu gut. Ich habe gestern Nacht auch erstmal das Handtuch geworfen. Mann darf nicht vergessen wodurch Geld reinkommt und was nur (Lebens-)Zeit und Nerven kostet.
Wir haben ein Kunden, der gerne mein Delphi-Programm durch Python-Skripts an seine Bedürfnisse anpassen möchte. Durch deinen Erfahrungsbericht ist mir bewusst geworden, wie wichtig das "Abstand halten" ist, damit man sich nicht Probleme auf den Tisch zieht, die andere verursachen. Stelle mir nun eine TCP-Client Anbindung an meinen schon vorhandenen TCP-Server vor. Da kann der Kunde draußen spielen bis der Arzt kommt, ohne mein Programm mit in den Abgrund reißen zu können.

[himitsu]

Es gibt/gab auch noch die Windows Scripting API.
Das ist eine API, welche man in seinem Programm nutzt, wo sich dann auch andere Sprachen registrieren und somit genutzt werden können.

Diese zu implementieren war nicht das Problem, womit man erstmal JavaScript und VBScript zur Verfügung hat.
Über C# gibt es noch irgendwie eine Implementation für PowerShell und Python (wobei FinalBuilder eher vom Python abrät, laut dem Kommentar in deren ScriptingFenstern)

Die mir bekannte Implementation vom ActiveScripting hatte ich nicht zum Laufen bekommen ... k.A. ob es da noch drin vorhanden ist, seit es die kostenlose Version nicht mehr gibt und in der aktuellen Demo ist es auch nicht drin. (nach der Installation ist keine Registrierung zu finden)

Auch es gibt noch dutzende andere ScriptSprachen, welche dort registriert werden können ... angeblich auch irgendein PascalScript (diesbezüglich hatte ich noch nicht detailiert gesucht ... hab erstmal mit PowerShell, CommandLine/CMD und WSL gespielt und halb fertig)

Ob es diese Speicherlecks des Python auch m WSH gibt, weiß ich nicht ... wie gesagt, die Installation davon funktioniert aktuell nicht mehr
und selbst das Python dort zu registrieren hab ich noch nicht hinbekommen (und falls doch, dann würde ich dort "meine" Speicherlecks natürlich mitbringen).
3 bis 12 oder mehr MB pro Ausführung, klingt nicht viel, aber 100 Mal gemacht, ist ein 32 Bit-Prozess im Arsch.

https://www.delphipraxis.net/214004-...-host-wsh.html