Python im Delphi ausführen (geht nicht)

[himitsu]

Moin,

nutzt hier irgenwer Python direkt in seiner Anwendung?

https://github.com/pyscripter/python4delphi
https://github.com/python/cpython
https://www.python.org/downloads/


Aktuell haben wir noch die Python.exe, wo Input und Output ins Programm umgeleitet sind (CreateProcess)
und jetzt wollten wir uns direkt mit der Python*.dll verbinden.

Erstmal, da dort die Fehlerbehandlung einfacher würde und vor allem auch für die Übergabe von Variablen. (später auch Zugriff auf Funktion und Klassen im Delphi)


Derzeit spielen wir etwas mit Python4Delphi rum
und wöllten eigenlich am Liebsten das Python direkt aus "unserem" Programmverzeichnis nehmen, anstatt "irgendeiner" (nicht)installierten Version. (auf den Rechnern unserer Kunden)

DLLName und DLLPath kann man "eigentlich" in der TPythonEngine angeben,
aber es raucht wortlos ALLES ab. (nur mit einer "richtigen" Installation läuft es bisher)

Bisher sind wir so weit, dass wir wissen es bricht im Py_Initialize ab.
Wir hatten auch gehört, dass Py_Initialize blöd ist und man besser Py_InitializeEx verwenden soll. (geändert, aber natürlich kein Unterschied)
Im Assmbler dann etweas reingedebuggt und es bricht im letzten CALL innerhalb von Py_InitializeEx ab,
dann den Quellcode besorgt und ....

und jetzt würde ich die Python-Entwickler liebendgern erwürgen
und den Entwickler von Python4Delphi auch ein bisschen.



Wie sind denn eure Erfahrungen?



Wir wissen noch nicht warum, aber wenigstens nun erstmal wo es abraucht.

Also genauer beendet sich das Programm, sobald die Form mit dieser Komponente geladen wird.
Keine Exception ... einfach zu und weg.

TPythonEngine.AfterLoad -> TPythonEngine.Initialize -> Py_Initialize -> Py_InitializeFromConfig -> ...
... -> _PyStatus_EXCEPTION -> Py_ExitStatusException -> Exit oder Write(stderr)+Exit

Code:

// pylifecycle.c

void
Py_InitializeEx(int install_sigs)
{
    PyStatus status;

    status = _PyRuntime_Initialize();
    if (_PyStatus_EXCEPTION(status)) {
        Py_ExitStatusException(status);
    }
    _PyRuntimeState *runtime = &_PyRuntime;

    if (runtime->initialized) {
        /* bpo-33932: Calling Py_Initialize() twice does nothing. */
        return;
    }

    PyConfig config;
    _PyConfig_InitCompatConfig(&config);

    config.install_signal_handlers = install_sigs;

    status = Py_InitializeFromConfig(&config);
    if (_PyStatus_EXCEPTION(status)) {
        Py_ExitStatusException(status);
    }
}

void _Py_NO_RETURN
Py_ExitStatusException(PyStatus status)
{
    if (_PyStatus_IS_EXIT(status)) {
        exit(status.exitcode);
    }
    else if (_PyStatus_IS_ERROR(status)) {
        fatal_error(stderr, 1, status.func, status.err_msg, 1);
    }
    else {
        Py_FatalError("Py_ExitStatusException() must not be called on success");
    }
}

void
Py_Initialize(void)
{
    Py_InitializeEx(1);
}

Fazit: Als "Fehlerbehandlung" beendet diese besch**** Komponente einfach so den kompletten Prozess (Halt/Exit/ExitProcess), anstatt z.B. eine Exception zu werfen (oder etwas mit Fehlercodes, innerhalb des Programms).

Wie im fatal_error zu sehen, würde ein Fehlertext eventuell auf die Console (strerr) ausgegeben.
Natürlich geil, dass eine VCL-Anwendung keine Console hat und selbst mit Console geht das Fenster bei Programmende auch sofort weg. (müsste man das dann also auch noch in der CMD.exe starten)


Auch im PascalWrapper (PythonEngine.pas) ist böswillig in ExitProcess versteckt,
denn das Property PythonEngine.FatalAbort ist standardmäßig True.

Delphi-Quellcode:

// wenn Fehler aufgetreten und Property FatalAbort=True
if FatalAbort then
  Quit;


procedure TDynamicDll.Quit;
begin
  if not( csDesigning in ComponentState ) then begin
{$IFDEF MSWINDOWS}
    MessageBox( GetActiveWindow, PChar(GetQuitMessage), 'Error', MB_TASKMODAL or MB_ICONSTOP );
    ExitProcess( 1 );
{$ELSE}
    WriteLn(ErrOutput, GetQuitMessage);
    Halt( 1 );
{$ENDIF}
  end;
end;

Wie kann man nur so dermaßen böswillig sein
und, nur weil es ein kleines Problem gibt, gleich den kompletten Prozess abwürgen,
anstatt nur, in dem einen Thread, einen Fehler zu werfen, welcher abgefangen und verarbeitert werden könnte?



Besonders cool ist auch die DLL-Suchfunktion der TPythonEngine (UseLastKnownVersion), welche auf einem Testrechner mit Installiertem Python (64 Bit) dessen DLL findet,
welche ... naja, in einem 32 Bit Programm geladen, geht es irgendwie nicht gut. :roll:

[TiGü]

Ein Kollege von mir beschäftigt sich gerade damit, eine große externe Bibliothek per Python4Delphi an unserer Programm anzuschließen.
Ich habe ihn den Thread per Mail geschickt und zitiere hier seine Antwort gekürzt.
Vielleicht hilft es dir weiter?
(EXTERNER BIBLIOTHEK = zensiert)

Zitat:

Ich hatte bis jetzt keine Probleme mit der Installation und Ausführung der Python-Schnittstelle in Delphi.

Ich habe es in 3 Rechner und 2 virtuelle Maschinen installiert und lief und läuft ohne Probleme und sehr stabil.

Die Benutzung externer DLL's zB von EXTERNER BIBLIOTHEK oder anderen mathematischen Bibliotheken, die unter C/C++ entwickelt sind (egal, ob über die Python Schnittstelle oder nicht), verlangt das verändern der FPU-Exception Masken, weil sie unterschiedlich sind, als in Delphi.
Für mehr Info kannst Du hier gucken:
https://stackoverflow.com/questions/...nd-twebbrowser

Die Entwickler von Python stellen als Hilfe die Funktion
MaskFPUExceptions(true);
zur Verfügung die genau das macht.

Das gleiche wird auch in der COM - Schnittstelle von EXTERNER BIBLIOTHEK gemacht.

Macht man das nicht, bekommt man Exceptions je nach Lust und Laune und ich vermute, der Typ mit dem Bug hat eventuell dieses Problem.

Ansonsten wäre dieses Unterforum vielleicht noch eine sinnvolle Anlaufstelle:
https://en.delphipraxis.net/?forumId=39

[TiGü]

Hier das angesprochene Maskieren der FPU-Exceptions:
https://github.com/pyscripter/python...kFPUExceptions

[mmw]

hallo,

bei mir läuft es so.

diese Datei

python-3.8.7-embed-win32.zip

runtergeladen (entpackt).

die Komponente wie im Anhang konfiguriert.

https://docs.python.org/3/using/wind...ows-embeddable

Ob's das Problem löst kann ich nicht sagen, zumindest kommt ein Ergebnis.

Gruß

[himitsu]

Jupp, so ähnlich hab ich das inzwischen auch zum Laufen bekommen.
* python-3.9.1-embed-win32.zip
* nichts konfiguriert
* und im Delphi wie bei dir, aber zusätzlich die mistigen Fatal*** auch auf False

Allerdings lässt sich der Pfad nicht dynamisch ändern. (OnBeforeLoad ist einen Hauch zu spät ... könnte maximal noch .Loaded überschreiben)
* drum, hab ich nun das Auto**** deaktiviert und versuche manuell zu laden
* war grade dabei meine zwei Demo-EXEn auszumisten und dann hochzuladen

* mit hartcodiertem Pfad geht es nun
* aber da das Programm selten im selben Pfad liegt .......


Mit AutoLoad hab ich auch noch das Problem, dass ich Variablen erst manuell löschen muß, da sie nach dem Execute erhalten bleiben, in den nächsten Aufrufen.
* grundsätzlich erstmal gut, da wir unser InitScript einzeln ausführen können und es nicht ins ArbeitsScript einfügen müssen. (bei einem Fehler würden dann nun endlich mal die Zeilennummern stimmen)
* aber zwischen der Ausführung von zwei Aufgaben sollten die Variablen nicht erhalten bleiben (früher einfach, da die Python.exe sich am Schulß eh immer beendete)
* auf die Schnelle aber nur ein Python-Script zum Löschen gefunden (im Delphi den Zugriff auf die Variablen noch nicht rausgefunden/verstanden ... egal, geht erstmal)


Also erstmal was halbwegs Nutzbbares hinbekommen,
aber nun noch versuchen das AutoLoad durch was Manuelles zu ersetzen

mit AutoLoad

Delphi-Quellcode:

procedure TForm9.PythonEngine1BeforeLoad(Sender: TObject);
begin
  { zu spät ... muß schon vor/in .Loaded erledigt worden sein, drum stehts erstmal wieder in der DFM }
  //PythonEngine1.DllPath             := EdDllPath.Text;
  //PythonEngine1.DllName             := EdDllName.Text;
  //PythonEngine1.RegVersion          := '';
  //PythonEngine1.UseLastKnownVersion := False;

  // muß vor PythonEngine1.Initialize aufgerufen werden.
  // und da PythonEngine1.AutoLoad=True .....
  PythonEngine1.InitScript.Text := EdGlobalScript.Text;
end;

procedure TForm9.BtExecCheckClick(Sender: TObject);
begin
  EdOutput.Clear;

  //PythonEngine1.ExecString(EdInitScript.Text);
  EdResult.Text := BoolToStr(PythonEngine1.CheckExecSyntax(EdExecScript.Text), True);
end;

procedure TForm9.BtExecClick(Sender: TObject);
begin
  //PythonEngine1.InitScript.Text := EdGlobalScript.Text;
  try
    EdResult.Clear;
    EdOutput.Clear;

    // Variablen der letzten Ausführungen löschen
    { bissl was versucht, aber nichts half
    PythonEngine1.GlobalVars := nil;
    PythonEngine1.LocalVars := nil;
    PythonModule1.ClearVars;
    }
    PythonEngine1.ExecString(
        'for name in dir(): '#10
      + '  if not name.startswith("__"): '#10
      + '    del globals()[name] '#10
      + 'for name in dir(): '#10
      + '  if not name.startswith("__"): '#10
      + '    del locals()[name] '#10
      + 'del name');

    if Trim(EdInitScript.Text) <> '' then
      PythonEngine1.ExecString(EdInitScript.Text);
    PythonEngine1.ExecString(EdExecScript.Text);
  except
    on E: Exception do
      EdResult.Text := E.Message;
  end;
end;

ohne AutoLoad (aber im Initialize knallt eine Zugriffsverletzung bei Addr 0000)

Delphi-Quellcode:

procedure TForm9.BtExecClick(Sender: TObject);
begin
  if not PythonEngine1.IsHandleValid then begin
    PythonEngine1.DllPath             := EdDllPath.Text;
    PythonEngine1.DllName             := EdDllName.Text;
    PythonEngine1.RegVersion          := '';
    PythonEngine1.UseLastKnownVersion := False;
    PythonEngine1.LoadDll;
  end;

  if not PythonEngine1.Initialized then begin
    PythonEngine1.InitScript.Text := EdGlobalScript.Text;
    PythonEngine1.Initialize;
  end;
  try

    try
      EdResult.Clear;
      EdOutput.Clear;

//      // Variablen der letzten Ausführungen löschen
//      { bissl was versucht, aber nichts half
//      PythonEngine1.GlobalVars := nil;
//      PythonEngine1.LocalVars := nil;
//      PythonModule1.ClearVars;
//      }
//      PythonEngine1.ExecString(
//          'for name in dir(): '#10
//        + '  if not name.startswith("__"): '#10
//        + '    del globals()[name] '#10
//        + 'for name in dir(): '#10
//        + '  if not name.startswith("__"): '#10
//        + '    del locals()[name] '#10
//        + 'del name');

      if Trim(EdInitScript.Text) <> '' then
        PythonEngine1.ExecString(EdInitScript.Text);
      PythonEngine1.ExecString(EdExecScript.Text);
    except
      on E: Exception do
        EdResult.Text := E.Message;
    end;

  finally
    PythonEngine1.Finalize;
  end;
end;

[Der schöne Günther]

Ich habe mit Python nichts am Hut, aber Kiriakos "pyscripter" Vlahos ist in der englischen Delphi-Praxis aktiv und es gibt dort sogar ein eigenes Unterforum.

[mmw]

hallo,

bringt es vielleicht

Delphi-Quellcode:

 if not PythonEngine1.Initialized then begin
    PythonEngine1.InitScript.Text := EdGlobalScript.Text;
    PythonEngine1.Initialize;
  end;

PythonEngine1.Initialize;

durch

PythonEngine1.LoadDLL

zu ersetzen

Gruß

[TiGü]

Nur vom reinen Doku lesen sind mir die folgenden Punkte aufgefallen.
Ich habe sie im Quelltextschnipsel ergänzt und mit Kommentar versehen.
https://github.com/pyscripter/python.../FindingPython

Zitat:

If you want to use a specific unregistered version set the following properties
DLLName e.g. python38.dll
RegVersion e.g 3.8
Set UseLastKnownVerion property to False
Set the DLLPath to the path where the DLL is located
Set the AutoLoad property to False
In your FormCreate event handler of the MainForm or in another suitable place run the following assuming that PythonEngine is the name of the component
PythonEngine.SetPythonHome('your python installation directory')
PythonEngine.LoadDLL

Delphi-Quellcode:

procedure TForm9.BtExecClick(Sender: TObject);
begin
  if not PythonEngine1.IsHandleValid then begin
    PythonEngine1.DllPath := EdDllPath.Text; // hier ist die Bitness sichergestellt? Manchmal hat man ja Tomaten auf den Augen und versucht stundenlang eine 64-Bit DLL in einem 32-Bit Prozess zu laden
    PythonEngine1.DllName := EdDllName.Text;
    PythonEngine1.RegVersion := ''; // fehlt, da muss sowas wie 3.9 rein
    PythonEngine1.UseLastKnownVersion := False;
    PythonEngine1.AutoLoad := False // hat gefehlt 
    PythonEngine1.SetPythonHome('your python installation directory'); // hat gefehlt (ggf. Inhalt aus PythonEngine1.DllPath probieren)
    MaskFPUExceptions(True); // hat gefehlt, vielleicht hilfreich
    PythonEngine1.LoadDll;
  end;

  if not PythonEngine1.Initialized then begin
    PythonEngine1.InitScript.Text := EdGlobalScript.Text;
    PythonEngine1.Initialize;
  end;
...
end;

[himitsu]

@mmw: Das LoadDll steht 3 Zeilen drüber drin. :angle:


SetPythonHome und MaskFPUExceptions .... muß noch ausprobiert werden.


Also, Project1 hat eine PythonEngine und lässt Python über die ganze Laufzeit geladen/initialisiert.
* das funktioniert inzwischen erstmal
* Die Variablen müssen aber manuell gelöscht werden (hab noch keine "Reset/Clear-Funktion gefunden), damit sie keine negativen Auswirkungen auf nachfolgende Scriptausführungen haben können.
-> z.B. einmal ausführen, dann die/eine Variablen-Zuweisung im InitScript oder Script löschen/auskommentieren ... und ohne das DELETE (CheckBox deaktiviert), ist die Variable bei der nächsten Ausführung immernoch da
* Erstellte Funktionen/Klassen und geladene Module müssten vermutlich auch noch gelöscht/entladen werden, vor/nach/zwischen den Aufrufen.

In Project2 hab ich versucht das Python vor/nach jeder Aufgabe neu zu initialisieren, bzw. die DLL komplett neu zu laden.
* beim ersten Durchlauf geht es
* und nachfolgend kommt dann nie wieder was raus

* hab schon gesehen, dass RedirectIO im Finalize auf False gesetzt wird,
aber es vor dem Initialize wieder auf True zu setzen knallt dann, da wohl die internen IO-Funktionen verschwunden sind, bzw. vielleicht auch das ganze FIOPythonModule.


Auch hab ich noch nicht ausprobiert, wenn es mehrere Forms mit einer TPythonEngine gibt,
welche öfters erstellt/freigeben werden und eventuell auch gleichzeitig existieren.
[Edit]
Hab 'nen Erstellenbutton in die Demos gebaut.
Und beim Erstellen der zweiten Form ....

Zitat:

There is already one instance of TPythonEngine running

Bleibt noch der Versuch TPythonEngine manuell zu erstellen, den Code auszuführen und sofort wieder freizugeben. (wenn sich das "running" nicht beenden/neustarten lässt)
(in der Hoffnung, dass dort das funktioniert, was in Project2 nicht geht, also mehrmals die DLL neu zu laden/initialisieren)

Ansonsten bleibt wohl nur noch die Möglichkeit einer globalen Instanz, wo dann Variablen und so manuell gelöscht werden müsse, wie in Project1.
[/Edit]


Das Ziel ist es, am Ende z.B.

Delphi-Quellcode:

ExtractFilePath(Application.ExeName) + 'Python\python123.dll'

für DllPath/DllName/SetPythonHome zu verwenden,
um eine "definierte" Python-Version nutzen zu können, unabhängig davon ob oder was für eine Version im Windows installiert ist.
(es wäre zu schön, wenn UseLastKnownVersion nicht sonstwo, sondern nur im DllPath suchen würde, wenn dort etwas angegeben wurde)

Also eine der Embeddeable liegt in unserem Programmverzeichnis
https://www.python.org/downloads/windows/
und Jene wird dann verwendet.
Aktuell muß noch manuell der DllPath und DllName in den Project1/2 eingestellt werden. (aber ich versuche schon diese Werte aus Variablen/Edits per Code zuzuweisen um zu sehen, ob sie auch programmseitig änderbar sind, während/nachdem die Form/Komponente geladen wurde)


Im Prinzip kann/wird es auch mehrere Module (Form-Instanzen) geben, welche teilweise gleichzeitig geladen sind und jeder zu Beginn etwas/mehreres ausführt (nacheinander, da alles im Hauptthread).

[mmw]

Hallo,
das hatte ich gesehen.

im Project1 habe ich einen Button eigefuegt mit diesem Code

Delphi-Quellcode:

if not PythonEngine1.Initialized then begin
    PythonEngine1.DllName:='python38.dll';
    PythonEngine1.DllPath:='d:\delphi10';
    PythonEngine1.LoadDll;
    edDllPath.Text:=PythonEngine1.DllPath;
    edDllName.text:=PythonEngine1.DllName;
end;

das müsste das Problem doch lösen.

das 'Sript' beim Eval -Button' habe ich durch ein einfaches print (2*2) ersetzt, dann kommt da auch etwas,

vielleciht ist das hier nochInteressant.

https://riptutorial.com/de/python/to...-2-zu-python-3

Gruß

[mmw]

hallo,

das wäre auch möglich (als Beispiel, DB Modul ist nicht unbedingt die beste Lösung)

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);

var  cl:TEngineClient;

begin
datamodule3.PythonEngine1.AddClient(cl);
cl.engine.
cl.engine.
cl.usw
end;

Delphi-Quellcode:

procedure TDataModule3.DataModuleDestroy(Sender: TObject);

var cl:TEngineClient;
     i:Integer;

begin
 for i:=PythonEngine1.ClientCount-1 downto 0 do
  begin
   cl:=PythonEngine1.Clients[i];
   PythonEngine1.RemoveClient(cl);
 end;

end;

[himitsu]

Zitat:

das 'Sript' beim Eval -Button' habe ich durch ein einfaches print (2*2) ersetzt, dann kommt da auch etwas,

Schau mal ganz unten ins Result-Edit :zwinker:

Eval ist was ganz Anderes ... print ist dort falsch (außer z.B. für's Logging oder Debugging)
Und ja, das was Eval macht, könnte man auch durch print im Exec lösen,
aber beim Exec kommt immer ein String raus, während es beim Eval ein Object ist (z.B. ein Float ohne irgendwelche Rundungen in der String-Darstellung) und es ist kein IO-Handler nötig.

Run/Exec (Execute an Script) führt "Scripte" aus (auch mehrere Befehle), wobei die Daten meistens via "print" in der Ausgabe landen.

Eval (Evaluate an Expression) führt nur eine "Berechnung" durch und gibt direkt als Result (nicht via IO) den Wert zurück.
(praktisch das, was man einer Variable zuweisen oder in einem IF benutzen kann)
Hier kann man aber "zusätzlich" über IO eventuelle Statusmeldungen, Logging, Fehlermeldungen usw. sehen,
aber das "eigentlich" Ergebnis eben via Result, als ein Python-Objekt.
https://riptutorial.com/de/python/ex...rucks-mit-eval



Also das mit der Engine sieht interessant aus.

[mmw]

Hallo

stimmt, aber hat bis jetzt nicht erhofften Erfolg gehabt.

aktueller stand

Delphi-Quellcode:

procedure TForm1.FormActivate(Sender: TObject);

begin

if PythonEngine1.Initialized then
        PythonEngine1.Finalize

  else begin
    PythonEngine1.DllName:='python38.dll';
    PythonEngine1.DllPath:='d:\delphi10';
    edDllPath.Text:=PythonEngine1.DllPath;
    edDllName.text:=PythonEngine1.DllName;

    PythonEngine1.LoadDll;


end;
end;

klappt ganz gut, das script im exec button functioniert nur aber nur bei dem jeweils neu erzeugten Formular.

Gruß

[himitsu]

Wie gesagt, das "einmalige" Laden funktioniert nun. (falsche Version und einmal der falsche Dateiname)
Wenn man das kranke "Fatal" in der PythonEngine deaktiviert (es darf niemals passieren, dass bei einem kleinen Fehler das gesamte Programm böswillig abgeschossen wird)

Ohne Fatal*** muß nach dem LoadDLL/Initialize nochmals IsHandleValid/Initialized geprüft werden, falls doch nicht geladen wurde. (es wäre bestimmt zu einfach gewesen dem LoadDLL ein Result zu geben oder ordentlich mit Exceptions zu arbeiten)

* Problem ist nun "nur" noch, dass zwischen den Scripten ein Reset erfolgen muß (Variablen und Imports zurücksetzen)
* bzw. die Engine mehrmals unabhängig parallel/nacheinander zu nutzen (oder das Python zwischendurch zu entladen und neu zu laden)

[hanvas]

Zitat:

Zitat von himitsu (Beitrag 1481348)

Moin,

nutzt hier irgenwer Python direkt in seiner Anwendung?

https://github.com/pyscripter/python4delphi

und den Entwickler von Python4Delphi auch ein bisschen.

Das musst Du nicht. Der Verantwortliche für dieses Verhalten der Komponenten, einer der Ursprungsentwickler (Morgan Martinet , Dietmar Budelsky) von Python4Delphi, ist gerade erst verstorben. [1]

In der englischsprachigen Ausgabe der Delphi Praxis gibt es eine Art "Support" für Python4 Delphi. [2]

[1] https://huth.gemeinsam-trauern.net/B...etmar-budelsky

[2] https://en.delphipraxis.net/forum/39-python4delphi/

[mmw]

hallo,
ich hab's jetzt so gelöst. (Bemerkung: Ich benutze eine p4d-version von Mitte 2020, bei der aktuellen scheint sich was geändert zu haben)

in der Procedure

Delphi-Quellcode:

procedure TPythonEngine.Initialize;

ausdokumentiert
// raise Exception.Create('There is already one instance of TPythonEngine running' );

den Code eingefügt.

Delphi-Quellcode:

if Assigned(gPythonEngine) then begin
   gPythonEngine := Self;
   CheckRegistry;
   FInitialized := True;
   FIORedirected := False;
   InitSysPath;
   SetProgramArgs;
   GetTimeStructType;
   GetDateTimeTypes;

if RedirectIO and Assigned(FIO) then
    DoRedirectIO;

for i := 0 to ClientCount - 1 do
    with Clients[i] do
      if not Initialized then
        Initialize;
 if InitScript.Count > 0 then
    ExecStrings( InitScript );
  if Assigned(FOnAfterInit) then
    FOnAfterInit(Self);
  exit;
end;

Delphi-Quellcode:

procedure TForm1.FormActivate(Sender: TObject);


begin
    PythonEngine1.LoadDll;
end;

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);

begin
    PythonEngine1.DllName:='python38.dll';
    PythonEngine1.DllPath:='d:\delphi10';
    edDllPath.Text:=PythonEngine1.DllPath;
    edDllName.text:=PythonEngine1.DllName;
end;

bis jetzt funktioniert's. Ist natürlich nur für den persönlichen Gebrauch gedacht und auf eigene Verantwortung.

Gruß

[himitsu]

Aktuelles Ergebnis:


Also erstmal muß man unbedingt aufpassen welches Python installiert ist. (eigentlich klar, aber die Fehlerbehandlung ist bissl ungünstig ... man denkt der finded die Embedded- oder Installed-DLL nicht, dabei kann er sie nur nicht laden, wegen falscher Bitigkeit)
> bei Win32-Programm die 32-Bit-DLL (meistens scheint im Windows64 die 64-Bit-Version installiert zu sein, was in einem 32 Bit Programm nicht gut geht)

* Obwohl die Komponente ab Delphi 2010 ist

Zitat:

Delphi-Quellcode:

{$IFNDEF FPC}
  {$IFNDEF DELPHI2010_OR_HIGHER}
      Error! Delphi 2010 or higher is required!
  {$ENDIF}
{$ENDIF}

Lässt es sich im Delphi XE garnicht kompilieren (in der INC muß die ExtendedRTTI auskommentiert werden)

* Die Demos sind alle für ein installiertes Python ausgelegt (ohne Installation mit Embedded irgendwo rumliegend, muß jede Demo einzeln angepasst werden)
* Außerdem fehlen in den Projekten die Suchpfade zum ..\Source;..\Source\Vcl (so lassen sich die Demos auch nicht kompilieren)
* Im XE flog aus allen Demo-Projekten das Win64 und es wurde mit Win32 kompiliert (hier bin ich in 10.4 drauf reingefallen, dass es dort mit standardmäßig aktiven Win64 mit meinem 32-Bit-Python nicht ging, wo mein Kollege keine Probleme hatte)

* manuelles LoadDll+Initialize und Finalize+UnloadDll funktioniert irgendwie nicht ... beim zweiten Aufruf geht vieles nicht mehr, vor allem die wichtige IO-Redirection
* Aber alle Klassen manuell erstellen und nach jedem Execute wieder freigeben, das funktionierte letztendlich
> alle Instanzen erstellen und initialisieren, inkl. Erstellen von paar PascalFunktionen und setzen von Python-Variablen ... dauert nur knapp 60 Millisekungen (schneller als die 3-5 Sekunden vom Aufruf der Python.EXE)

[Slanco]

Hallo,

ich hoffe es ist inordnung wenn ich diesen Thread nochmals hervorhebe.
Ich habe Folgendes Problem.
Auf meiner Arbeitsmaschine ist Python wie gewünscht installiert. Wir nutzen auf unseren Rechner Delphi 10.42
hab damit paar kleine Sachen gebastelt die auch auf dem Rechner ganz normal laufen, danach hab ich nun versucht da wir nicht die möglichkeit haben Python
auf den Kundenrechnern zu installieren Python anhand der Dll auszuführen den

Delphi-Quellcode:

 if not PythonEngine.Initialized then begin
      PythonEngine.DllName:='python311.dll';
    PythonEngine.DllPath:=edit1.Text;;
      PythonEngine.LoadDll;
 end;

Einstellungen der Engine: Im Anhang

Ich hab leider nur die möglichkeit die passenden Dlls auf die Kundenrechner zu schmeißen und damit die Anwendung zu starten
aber auch wie bei dir beschrieben Raucht das ding Wortlos ab.

Ich komm leider nicht weiter, vielleicht könnte ihr mir Helfen oder zumindest in die richtige Richtung weisen.
Achja muss x64 sein!

Grüße

[himitsu]

Einfach die irgendeine DLL direkt zu nutzen geht nicht (so einfach).


Du brauchst die Embedded-Version

https://www.python.org/downloads/windows/

Anschließend kann man z.B. entweder auf die python3.dll oder die pyphon38.dll zugreifen. (4 und 4* für die nächste Majorversion)

Erstere ist ein Dummy, welcher die Aufrufe zur aktuellen python3*.dll durchreicht.
Letzere kann man nehmen um im Verzeichnis (mit mehreren Version) geziehlt eine bestimmte Version zunutzen.
Außerdem braucht die Automatik des Python4Delphi die DLL mit der genauen Version, weil der Ersteller so krank ist die Versionsnummer aus dem Dateinamen auszulesen, anstatt über die API (exportierte DLL-Funktion) und darüber dann Versionsabhängiges in seiner Komponente steuert. :wall:




Wir nutzen absichtlich nicht die installierte Version.
* erstmal sind wir so unabhängiger von externen Dingen (z.B. wenn der Kunde in seinem System änderungen vornimmmt)
* * vor Alem bei solch Mist wie Adobes PDF waren wir ständig nach automatischen Updates auf neue Probleme gestoßen
* auch müssen wir so das nicht im System installieren (es liegt einfach nur im Verzeichnis / in einem Unterverzeichnis unseres Programms)

* außerdem haben wir das so auch komplett in der Versionierung
* und wir können auch parallel unterschiedliche Versionen gleichzeitig nutzen (z.B. alte und neue Version unseres Programms, inkl. jeweils eigener Python-Version)




Bis auf rückschreibbare Variablen, aus Delphi heraus, haben wir fast alles zum Laufen bekommen.

[Slanco]

Hi Danke für die Antwort.

schade.. leider kann ich beim Kunden keine Verzeichnisse, exe oder dergleiche drauf werfen.. (Sicherheitsgründe),
wir haben lediglich die Möglichkeit DLL mitzugeben, wäre ja in diesem fall Python311.dll gewesen.


Grüße

[himitsu]

Die Beiden Python*.exe braucht man nicht.
sie sind nur nötig, wenn man über die Console ein Python-Script ausführen will.

Als Embedded-Version innerhalb des eigenen Prozesses, also mit der DLL (z.B. mit Python4Delphi oder sonstwie) braucht es nur die paar DLLs (die EXEn in der ZIP kann man weglassen) und die pyd (vorkompilierte py-ScriptBibliotheken) und die python*.zip (nicht entpacken ... mit noch mehr pyc drin, also vorkompilierten py-scripten) ... zumindesten die py/pyc/pyd/zip, was man via "import" benutzen will

[Slanco]

vielen Lieben dank.
Ich werde das ganze mal versuchen auf ein Minimum zu reduzieren und
nach zu schauen welche dlls bzw pyd datei benötigt werden.
vielleicht krieg ich das Argumentiert.