Python im Delphi ausführen (geht nicht)

[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